Насколько хороша Subversion при хранении большого количества двоичных файлов?

Я ищу место для размещения нескольких ГБ документов (в основном .doc и .xls). У моей команды уже есть сервер Subversion, настроенный для управления создаваемыми нами документами, поэтому я предпочел бы использовать это, если это возможно. Насколько хорошо Subversion справится со всеми этими дополнительными вещами? Большая часть из них - устаревшая информация и будет иметь только одну версию, но возможно, что несколько документов могут быть обновлены.

Я был предупрежден, что SVN не особенно подходит для большого двоичного файла. Я с осторожностью пытаюсь проверить, работает ли он, поскольку они всегда будут в истории хранилища, даже если я позже их удалю.

Любые альтернативы? Нам понадобится возможность комментировать и/или тегировать документы, но мы можем использовать услугу, подобную Delicious, в сочетании с URL-адресами для документов в SVN (или аналогичных).

В дальнейшем Меня не так беспокоит различие в двоичных файлах, поскольку, как указано выше, они не будут сильно меняться. Я в порядке с небольшими хлопотами, если они это делают - это не хуже, чем SharePoint.

Ответ 1

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

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

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

Итак,

1000 файлов 1 МБ = отлично.
100 10 МБ файлов = отлично
10 100 МБ файлов = отлично
1 > 1000 МБ файл = не очень хорошая идея.

Я надеюсь, что размер ваших документов вписывается в одну из прекрасных категорий:)

Ответ 2

В моей предыдущей компании мы устанавливаем Subversion для хранения файлов САПР. Файлы до 100 МБ были сохранены в Subversion. Если многие пользователи добавляют "большие файлы" на веб-сервер Subversion, это может быть узким местом. Однако инкрементные коммиты были в порядке.

Subversion хранит двоичную дельта. Фактически, на стороне сервера двоичные и текстовые файлы обрабатываются одинаково для хранения "дельта". Проверьте раздел "улучшения бинарной дельта-кодировки" на странице http://subversion.tigris.org/svn_1.4_releasenotes.html. В нем явно говорится: "Subversion использует алгоритм xdelta для вычисления различий между строками байтов" (а не строки "символов" ).

Только для эксперимента я сохранил 10 версий САПР (файл части CATIA). В каждой версии я внес небольшие изменения в часть, а затем проверил размер репозитория на сервере. Общий размер был около 1.2x для примерно 10 версий (x - исходный размер файла).

Не забудьте установить свойство svn: needs-lock. По моему опыту, лучший способ - использовать "авто реквизиты" для установки svn: needs-lock на основе расширения файла.

Ответ 3

Мы построили наш subversion клиент именно для этого, так как у нас действительно были большие дизайнерские/консалтинговые задания, которые действительно нуждались в управлении версиями. У нас никогда не было проблем с этим.

Ответ 4

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

Ответ 5

Я лично использую Mercurial для выполнения таких задач. Я использовал его для хранения нескольких сотен гигабайтов медиа. Да, это занимает некоторое дисковое пространство, но дисковое пространство дешево. С Mercurial вы также получаете выгоду от его распределения, поэтому делая "checkout" или клонируйте, как известно в Mercurial, вы получаете полное репо, а не только снимок. Если ваш сервер когда-либо умирает, вы все еще в бизнесе.

Ответ 6

Из того, что я видел, Git очень быстро по сравнению с Subversion, и я слышал его несколько быстрее Mercurial, но только немного. Тем не менее, я специально не тестировал его с большими или большими двоичными файлами.

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

Я могу сказать это наверняка; Как только я привык к Git, я бы не стал возвращаться в Subversion. Когда мне приходится работать с репозиториями Subversion, я все еще использую Git хотя git -svn. Таким образом, я получаю все преимущества распределенного контроля версий, но по-прежнему имею очень хорошую поддержку для толкания, возвращаемого обратно в центральный репозиторий Subversion.

Ответ 7

Хорошо, что это займет много пространства, хранящего все, что в Subversion, я скажу вам многое. Subversion не хранит двоичные файлы через delta так, как хранит текстовые файлы. Это, вероятно, займет столько места, сколько просто для хранения кучи двоичных файлов на вашем жестком диске, плюс репозиторий.

У вас может быть tiddlywiki на стороне сервера, чтобы хранить URL-адреса в документах в Subversion.

Если они в основном являются файлами .doc и .xls, есть также Microsoft Sharepoint.