SparkleShare получает уведомление о локальных изменениях данных с помощью inotify, затем ждет, пока действия файловой системы не завершатся, и не начнет фиксировать и отправлять изменения на сервер через SSH. Чтобы узнать, когда новые файлы доступны, есть сервер, предоставленный разработчиками Sparkleshare, где Sparkleshare создает новый канал для каждого репозитория, чтобы push-уведомления можно было отправлять каждому экземпляру, подписанному на канал, при изменении файлов. Если это невозможно, SparkleShare возвращается к опросу.
Серверная часть полностью пассивна и вообще ничего не знает о SparkleShare, это просто git-репозиторий.
Теперь некоторые из моего опыта с управлением конфликтами и двоичными файлами, это может быть предвзятым:
Я пытался использовать SparkleShare уже полгода, но на прошлой неделе я сдался. Все идет хорошо, пока вы не внесете различные изменения на разных устройствах в автономном режиме. Это почти всегда приводило к тому, что мне приходилось разрешать конфликты вручную с моими не очень хорошими навыками. Насколько я знаю, при возникновении конфликта Sparkleshare пытается вернуть HEAD хранилища обратно в коммит, который является общим для обоих конфликтующих изменений, затем воспроизводит коммиты с сервера поверх него и затем пытается применить локальный изменения, но я не уверен в этом, и это не сработало для меня. Эта проблема в сочетании с некоторыми проблемами, которые есть у git с бинарными файлами, которые меняются, приводили к тому, что мой ЦП работал на 100% регулярно до разрешения конфликтов вручную. На одном из моих устройств со средой с низкой оперативной памятью он не мог даже клонировать одно из моих хранилищ, потому что у меня не хватало воспроизводимой памяти.
Я знаю, что вы не спрашивали моего совета о том, как использовать SparkleShare, но я советую вам не использовать его с двоичными файлами и / или файлами, которые быстро меняются, такими как savegames, некоторые файлы конфигурации и т.д.
