moytramoytra
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Jivchic
Задача сама синхронизации в таких условиях довольно сложная, думаю даже требует ручных рязрешений конфликтов. Пример, допустим был папка A, её скопировали в два места, потом в первом месте файлы папки засунули в подпапку и ещё в предачу изменили. А во втором месте тоже засунули в другого имени подпапку и тоже изменили. Теперь при синхронизации как программа узнает (даже если отгадает, какие файлы куда переместились), какую всё таки подпапку мы хотим иметь в финальной версии (синхронизированной). Ориентироваться на время/дату? Не особо надёжно... Думаю нужно уже пользователя спрашивать о том, как разрешить конфликт. Потом про изменения файлов, допустим это .pdf или .doc изменились, нельзя ведь просто слить бинарный кусочек изменения в одном месте и бинарный кусочек в другом, получится битый .pdf/doc. Для текстовых файлов ещё куда не шло, их можно соединить, типа исходников. Но как понимаю задача для более сложных форматов, которые нельзя просто взять и напичкать куски из разных версий...
Потому варианты слияния в такой ситуации:
1) Изменения в структуре директорий сливать согласно дате и времени (позаботится нужно только о синхронности часов на всех компьютерах используемых). Брать самую последнюю версию.
2) Изменения в одном и том же файле в разных местах - предлагать вручную синхронизировать, сообщая какой файл изменился.
Вообще моё решение было бы таким (программ не знаю подходящих, одну сам написал недавно, но она немного другую задачу решает): либо 1) используем интернет и сразу на ходу синхронизируем. DropBox тому хорошая тулса.
или если нет интернета 2) Носим с собой хотя бы маленькую флэшку, куда фиксируем текущую версию, точнее изменения в папке, пример: есть исходная папка A, запустили прожку, зафиксировали куда-нибудь (можно на флэшку, можно в интернет) состояние начальное (версия 1) папки A, далее скопировали куда-то её и довели до состояния B (версия 2), когда завершились с работой, фиксируем (запуском прожки) состояние версии 2 (тоже на флэшку или инет), далее идём и где-то ещё берём папку A и правим её до C (версия альтернативного ответвления, первая была A->B, а здесь A->C), сообщаем прожке, что мы из A сделали C (а не из B). И т.д. накопили кучу версий той же папки, если мы всё дерево альтернативных ответвлений сообщили программе, то мы можем вполне синхронизировать, она уже будет знать, как прходили пути изменения...
А если просто наголо давать несколько папок слить, без вопросов к пользователю (типа а какая структура папок или версия файла новее) не обойтись, или если обойтись можно напортачить и чтонибудь испортить...
Задача схожая в системах контроля версий исходников в программирования (Source Version Control) и там часто когда разные программисты правят одновременно файлы и папки те же, возникают иногда конфликты, которые программы контроля предлагают решить вручную, задавая вопросы типа 1) взять версию A или версию B, или их соединить (это если файл текстовой) и когда соединяет, то даёт возможность подредактировать, т.к. и исходники просто так не всегда можно склеить не испортив логики...
PS. Раз уж упоминал прожку, что писал... Это скриптик, аналог diff юниксового но для папок. DirPatch назвал. Ему даёшь левую и правую папку и он создаёт патч (старается как можно меньшего размера, инкрементарные изменения только), которым можно приобразовать левую папку в правую (не имея правой вообще). Т.е. DirPatch_Diff(L, R)->Patch, а потом DirPatch_Patch(L, Patch)->R, примерно так  . Использовал для хранения разных версий сетапов программы (например Lingvo x5 v15.0.511.0 и 15.0.592.5) так, чтобы хранить только базовую какую нибудь + набор патчей преобразующих эту базовую в остальные версии. А второе применение у меня было - базовая оригинальная программа, а патч - преобразовывает папку оригинальной программы во взломанную (ну и конечно только изменённые байты хранятся, не целиком файлы поломанные). Ну и задача скрипта самому найти изменения где и как на уровне папок. Альтернативный вариант тому, как я делал, будет левую и правую папку заархивировать методом Store (без сжатия) например 7z или RAR и далее на двух архивах прогнать XDelta или BSDiff (последний меньше создаёт патчи, но требует больше памяти и работает медленней). Ну а при восстановлении обратный процесс... |
