Комментарии 18
Весьма и весьма любопытно.
>мне не хотелось следить за каждой директорией в дереве директорий
Смотрите, у вас есть есть очень разветвленная структура папок. Половина из них имеет тяжелое содержимое, которое вы не хотите синхронизировать. Структуру папок менять тоже не хотите. Мне кажется удобнее, отлавливать изменения для каждой конкретной директории.
В том же Dropbox это нужно настраивать отдельно. И не особо удобно.
Смотрите, у вас есть есть очень разветвленная структура папок. Половина из них имеет тяжелое содержимое, которое вы не хотите синхронизировать. Структуру папок менять тоже не хотите. Мне кажется удобнее, отлавливать изменения для каждой конкретной директории.
В том же Dropbox это нужно настраивать отдельно. И не особо удобно.
Ага, вот как раз сейчас думаю об этом. В этом есть смысл. Selective sync в Dropbox просто ужасен — у меня он начал удалять содержимое папок, которые я убрал из синхронизации.
Когда спадет волна эйфории по поводу ковыряния в недрах Qt, думаю, что я сделаю поддержку синхронизации нескольких папок, а значит и выборочную синхронизацию.
Когда спадет волна эйфории по поводу ковыряния в недрах Qt, думаю, что я сделаю поддержку синхронизации нескольких папок, а значит и выборочную синхронизацию.
Другой пример (наверно, не по теме уже) — вам нужно синхронизировать папки которые, не являются поддиректориями одной и той же папки. В Dropbox так нельзя и это сильно расстраивает.
Согласен. Сейчас у меня все завязано на Unison и его профиль. Надо посмотреть может ли он синхронизировать сразу из нескольких папок. Хотя никто не мешает сделать более глубокую интеграцию с Unison'ом или использовать что–нибудь другое. Rsync, например.
А почему именно Unison?
На вики пишут, что разработчики его более не развивают и переключились на Harmony.
На вики пишут, что разработчики его более не развивают и переключились на Harmony.
Я сейчас как раз обдумываю оставаться ли с Unison'ом или использовать что–нибудь другое. Rsync кажется возможной заменой, но он не знает ничего про конфликты. Последний релиз rsync'а был примерно тогда же, когда и последний релиз Unison'а.
К минусам Unison'а я бы отнес его требовательность к версиям программы и то, что он написан на OCaml.
Плюсом для меня была простота использования и кросс–платформенность.
В идеале хотелось бы, чтобы была кросс–платформенная библиотека, которая умела бы синхронизировать папки через SSH. Но похоже, что такую библиотеку нужно писать самому.
К минусам Unison'а я бы отнес его требовательность к версиям программы и то, что он написан на OCaml.
Плюсом для меня была простота использования и кросс–платформенность.
В идеале хотелось бы, чтобы была кросс–платформенная библиотека, которая умела бы синхронизировать папки через SSH. Но похоже, что такую библиотеку нужно писать самому.
Маленький вопрос, если я вашу разработку начну использовать прямо сейчас для рабочих проектов — мне это ничем не будет грозить?
Сервер: Gentoo местной сборки. Клиента 2: Windows, Kubuntu.
Сервер: Gentoo местной сборки. Клиента 2: Windows, Kubuntu.
Отлично. Огромное спасибо. Я ждал, что кто-то, да сделает открытый аналог дропбокса.
Форкнул ваш проект, появится время — буду пилить под себя )
Форкнул ваш проект, появится время — буду пилить под себя )
А вот кстати, интересный вопрос.
Что делать, когда все место на сервере кончилось?
Выкидывать старое или не добавлять новое?
Или как-то выставить приоритет для файлов?
Например, как я понял, по горькому опыту, Dropbox выкидывает.
Но по какому принципу, я не осознал. Например, архивы он не тронул,
а стилевые .sty файлы куда-то пропали. Причем, тоже выборочно.
Что делать, когда все место на сервере кончилось?
Выкидывать старое или не добавлять новое?
Или как-то выставить приоритет для файлов?
Например, как я понял, по горькому опыту, Dropbox выкидывает.
Но по какому принципу, я не осознал. Например, архивы он не тронул,
а стилевые .sty файлы куда-то пропали. Причем, тоже выборочно.
Это зависит от реализации «движка синхронизации». Только что проверил, что делает Unison. Он сообщает, что синхронизация не прошла. При этом забивает доступное место настолько, насколько может. Например, не помещается у меня уже mp3 файл размером 4 мегабайта, но 2 еще войдут. Тогда после синхронизации, в папке–получателе будет файли с именем .unison.<file-name>..unison.tmp размером 2 мегабайта.
И еще мучает, вопрос. Как в таких случаях правильно поступать с симлинками и хардлинками. Допустим если оба воплощения хардлинка хотим синхронизировать, но в разных директориях. В идеале, надо на сервере тоже хранить как хардлинк, но по-моему это ненужная головная боль.
С симлинками аналогично. Хотя, самое интересное начинается, наверно начинается как раз тут. Особенно занятно, как завязывать ntfs-link и никсовый.
С симлинками аналогично. Хотя, самое интересное начинается, наверно начинается как раз тут. Особенно занятно, как завязывать ntfs-link и никсовый.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Синхронизация в стиле Dropbox на вашем собственном сервере