синхронизация папок и файлов
"поработал за А - синхронизировал - поработал за В - синхронизировал - вернулся к А"это халява. А вдруг случится - "Поработал за А, поработал за В - синхорнизировал"? Как тогда мержить предлагаешь?
предполагается, что тогда сам себе дурак.
решение нужно все-таки для меня одного в условиях "сначала синхронизируем, потом работаем, или не жалуемся"
решение нужно все-таки для меня одного в условиях "сначала синхронизируем, потом работаем, или не жалуемся"
пользовать один диск для обоих компов (на втором подключить как сетевой)
противоречит 2 закону робототехники: если можешь работать без геморроя - работай без геморроя 
Это два ноута, подключать внешний диск каждый раз - сакс, подключать один к другому - неработоспособно.
Это два ноута, подключать внешний диск каждый раз - сакс, подключать один к другому - неработоспособно.
подключать один к другому - неработоспособнопочему? А с чем тогда хочешь синхронизировать? Ну сделай внешний отдельный фтп и подключай как диск уже его
Имелись в виду именно два ноута. Подключаться могут только для синхронизации.
Если я услышал правильно, предлагалось использовать диск одного как сетевой для работы на другом - имхо, неудобно.
Сокращу вводную: Портфель - совсем уродское создание? о нем какие-то мрачные воспоминания с молодости. Есть ли что-то лучше штатного Briefcase?
Если я услышал правильно, предлагалось использовать диск одного как сетевой для работы на другом - имхо, неудобно.
Сокращу вводную: Портфель - совсем уродское создание? о нем какие-то мрачные воспоминания с молодости. Есть ли что-то лучше штатного Briefcase?
вот тебе мой кривой совет:
бери любой pgp диск, и делай две копии его. И регулярно при подключении с одного ноута на другой копируй их. Это не самое удобное удобное решение, но легко осуществимое. Трудно осуществимое, но максимально удобное, надо искать в виде специальной ФС. Могу примерное ТЗ на эту ФС привести:
1. Необходимо хранить все данные и метаданные в зашифрованном виде, очевидно они должны паролиться пользователем.
2. Она должна работать автономно и однораногово на нескольких локациях (как минимум с дискретной синхронизацией по сети - не обязательно всегда быть онлайн).
3. Работать в двух режимах: онлайн и оффлайн. В первом случае работает непрерывная жесткая синхронизация среди всех включенных репозиториев, файлы лочиться должны одновременно, во втором случае - при первом же попадании в онлайн начинает фоновая активная синхронизация и merge.
4. Уметь мержить в случае рассинхронизации, желательно уметь настраивать политику, в качестве дефолтной неплохо было бы оставлять самые новые файлы, а более старые (но новее того момента, с которого отсчитывается рассинхронизация) бранчить с другими именами (пользователь, если надо сам ручками потом замержит). Возможно для определенных файлов (по регэкспу или еще как) иметь возможность запускать скрипты для "умной" синхронизации (логи, например замечательно сливаются в автоматическом режиме). Эти скрипты тоже следует считать частью метаинформации, как и прочие настройки ФС, чтобы иметь возможность без дополнительных вопросов для пользователя масштабироваться для нового репозитория
5. Работать независимо и с некоторой избыточностью, количество локальных репозиториев задается целым числом, избыточность - вещественным. И то и другое должно быть позволено менять на лету. Для твоей цели избыточность должна быть выше количества локальных репозиториев с тем, чтобы на каждом из них гарантировано было по одной копии. Очевидно, что для этого избыточность должна достигаться равномерным размазыванием данных по репозиториям, с минимальной избыточностью в пределах одного репозитория. Опционально репозитории могут объединяться в группы с тем, чтобы между группами была равномерно размазана избыточность, что может быть удобно если группировать все репозитории в одной локалке: в связи с тем, что шансов на отказ локалки существенно меньше чем на разрыв связи с интернетом, было бы хорошо если в локалке была бы возможно более полная версия. Так же опционально было бы хорошо устанавливать разные коэффициенты избыточности на данные и на метаданные.
6. Опционально уметь работать в двух модах: авторизованном и только на хранение. В первом случае вводится пользовательский пароль и после этого возможно писать и читать информацию на смонтированном диске. Во втором случае локального доступа к репозиторию нет, он управляется только через сеть (авторизуется уже авторизованном пользователем репозиторием) и используется только для хранения информации.
7. Опционально кроссплатформенность. Понятно, думаю, зачем.
8. Совсем опционально сделать такую ФС многопользовательской с правами доступа, настраиваемой для разных пользователей.
9. Ну и наверное было бы неплохо, если бы система была достаточно эффективной, а шедулер для дисковых и сетевых операций достаточно умным. И как минимум нужен свой алгоритм определения пропускных способностей связи в облаке и вычисления оптимальных маршрутов.
Собственно, такое комплексное решение я и сам ищу, вот только не могу найти почему-то.
бери любой pgp диск, и делай две копии его. И регулярно при подключении с одного ноута на другой копируй их. Это не самое удобное удобное решение, но легко осуществимое. Трудно осуществимое, но максимально удобное, надо искать в виде специальной ФС. Могу примерное ТЗ на эту ФС привести:
1. Необходимо хранить все данные и метаданные в зашифрованном виде, очевидно они должны паролиться пользователем.
2. Она должна работать автономно и однораногово на нескольких локациях (как минимум с дискретной синхронизацией по сети - не обязательно всегда быть онлайн).
3. Работать в двух режимах: онлайн и оффлайн. В первом случае работает непрерывная жесткая синхронизация среди всех включенных репозиториев, файлы лочиться должны одновременно, во втором случае - при первом же попадании в онлайн начинает фоновая активная синхронизация и merge.
4. Уметь мержить в случае рассинхронизации, желательно уметь настраивать политику, в качестве дефолтной неплохо было бы оставлять самые новые файлы, а более старые (но новее того момента, с которого отсчитывается рассинхронизация) бранчить с другими именами (пользователь, если надо сам ручками потом замержит). Возможно для определенных файлов (по регэкспу или еще как) иметь возможность запускать скрипты для "умной" синхронизации (логи, например замечательно сливаются в автоматическом режиме). Эти скрипты тоже следует считать частью метаинформации, как и прочие настройки ФС, чтобы иметь возможность без дополнительных вопросов для пользователя масштабироваться для нового репозитория
5. Работать независимо и с некоторой избыточностью, количество локальных репозиториев задается целым числом, избыточность - вещественным. И то и другое должно быть позволено менять на лету. Для твоей цели избыточность должна быть выше количества локальных репозиториев с тем, чтобы на каждом из них гарантировано было по одной копии. Очевидно, что для этого избыточность должна достигаться равномерным размазыванием данных по репозиториям, с минимальной избыточностью в пределах одного репозитория. Опционально репозитории могут объединяться в группы с тем, чтобы между группами была равномерно размазана избыточность, что может быть удобно если группировать все репозитории в одной локалке: в связи с тем, что шансов на отказ локалки существенно меньше чем на разрыв связи с интернетом, было бы хорошо если в локалке была бы возможно более полная версия. Так же опционально было бы хорошо устанавливать разные коэффициенты избыточности на данные и на метаданные.
6. Опционально уметь работать в двух модах: авторизованном и только на хранение. В первом случае вводится пользовательский пароль и после этого возможно писать и читать информацию на смонтированном диске. Во втором случае локального доступа к репозиторию нет, он управляется только через сеть (авторизуется уже авторизованном пользователем репозиторием) и используется только для хранения информации.
7. Опционально кроссплатформенность. Понятно, думаю, зачем.
8. Совсем опционально сделать такую ФС многопользовательской с правами доступа, настраиваемой для разных пользователей.
9. Ну и наверное было бы неплохо, если бы система была достаточно эффективной, а шедулер для дисковых и сетевых операций достаточно умным. И как минимум нужен свой алгоритм определения пропускных способностей связи в облаке и вычисления оптимальных маршрутов.
Собственно, такое комплексное решение я и сам ищу, вот только не могу найти почему-то.
я ни слова не разобрал!
я вот как раз тоже. только предлоги.
Нефигово написано, и многое на мой ламерский взгляд по делу.
Но с pgp диском, ЕМНИП, есть загвоздка: если файл побъется, то побъется все файло, которое на нем есть. сразу. что не есть гут.
2 возражение - объем данных около 20 Гб, перед каждым сеансом 20 ГБ стирать потом копировать...что-то во мне протестует.
попробую пока портфелем, что ли.
Но с pgp диском, ЕМНИП, есть загвоздка: если файл побъется, то побъется все файло, которое на нем есть. сразу. что не есть гут.
2 возражение - объем данных около 20 Гб, перед каждым сеансом 20 ГБ стирать потом копировать...что-то во мне протестует.
попробую пока портфелем, что ли.
У тотал коммандера есть опция "синхронизировать каталоги", очень удобная имхо. Работаешь в расшаренных на чтение+запись папках, а при подключении синхронизируешь одной кнопкой.
а если типа SVN?..
rsync -avHAX --delete-after source/ clone/
Видимо, самый рабочий вариант из предложенных
rsyncпод винду нет, к сожалению
АПД.
А, нет, нашел под винду cwrsync
Оставить комментарий
alex211151
опытные камрады, просьба подсказать решение:есть два ноута. работать приходится то за одним, то за другим.
Есть ли хорошее решение по синхронизации рабочих папок и файлов?
Вводную можно сжать до "поработал за А - синхронизировал - поработал за В - синхронизировал - вернулся к А"
Интересует именно личный опыт- что действительно работает и при этом не выеживается?