[хочется странного] git для инкрементных бекапов файлопомойки

Уж очень привлекает возможностью восстановить файл любой ревизии.

Насколько я понял из рассказа Линуса про git, git отслеживает изменения в содержимом, а не файлы. Я бы посмотрел на что-нибудь попроще, типа rdiff-backup или backuppc.

ну как именно это происходит внутри наверно не так уж и важно, главное что гит гарантирует достоверность данных и возможность изъять любую версию файла. И вроде с производительностью у него все более чем ок.

как именно это происходит внутри наверно не так уж и важно

важно, для --

с производительностью у него все более чем ок.

Ну, то есть git для файлопомойки — это overkill, я думаю. Посмотрите (или почитайте) доклад Линуса про git в Google, он рассказывает там, для чего git был придуман.

я смотрел этот доклад и читал документацию. Это хорошая система контроля версий чего угодно. Для файлопомойки с рабочей документацией по-моему самое оно. Чего я доподлинно не знаю так это того, насколько хорош гит при контроле версий бинарный файлов.

где-то встречал copy-on-write fs для us с мониторингом версий.
гугли.

про git не знаю, про mercurial недавно тему поднимали, сошлись во мнении что вроде как очень эффективно и в плане скорости и в плане потребляемого места.

Может, не в тему, но где-то после 2.6.28 версии в ядре есть некая NILFS. Может подойдёт?

Тебе сюда и не парь людям мозг.

каждое мелкое изменение файлов будет запоминаться? Мне бы с настраиваемым интервалом (допустим, раз в сутки по ночам делать снепшоты).

> очень эффективно и в плане скорости и в плане потребляемого места.

Будет оверхед около 100% при храниени фильмов/музыки. Так как что гит, что меркуриал хранят копии (хоть и пожатые, но для уже сжатых файлов мультимедии пофигу) контента.

В общем требую обьяснения, почему гит/меркуриал «очень эффективны в плане потребляемого места»

если у тебя файл полностью изменился то для хранения истории при любом алгоритме оферхед 100%.

Если файл изменился частично то будут сохранены только изменения. По крайней мере на лоре единогласно к этому мнению пришли в пред. обсуждении.

Ты лутше обьясн какие такие частичные изменения у тебя будут в файлах каждый день.

> если у тебя файл полностью изменился то для хранения истории при любом алгоритме оферхед 100%.

Ты не понял. Смотри: если у тебя 500гиб музыки + фильмов, то оверхед уже будет +500гиб (итого 1тиб занято, половина в .git/* или в .hg/*). Т.е. ты не можешь залить 300гиб фильмов/музыки на 500гиб жесткий диск, так как что git, что hg нужно где-то хранить копию файлов (+300гиг).

Возьмём ZFS - залили 500гиб на 1тиб хард, сводобно - 500гиб (считаем оверхед на стурктуры ФС незначительными). Сделали снапшот - свободного места стало, к примеру, 499гиб. Копии нигде не хранятся, оверхеды примерно в два раза меньше. Самое прикольное - снапшоты в ZFS можно маунтить и чистить. Всё просто и удобно :)

С этой точки зрения да, без working dir никак.

допустим, из 10000 файлов в среднем за день меняются 20 .xls файлов, создается допустим 10 новых .doc и .xls

но ведь .git/ может быть на удаленном сервере (nfs, например).