Насколько хорошо Subversion в хранении большого количества бинарных файлов?
Я ищу место для размещения нескольких ГБ документов (в основном .doc а также .xls). В моей команде уже есть сервер Subversion, настроенный для управления создаваемыми нами документами, поэтому я бы предпочел использовать его, если это возможно. Насколько хорошо Subversion справится со всеми этими дополнительными вещами? Большая часть информации унаследована и будет иметь только одну версию, но возможно, что несколько документов могут быть обновлены.
Меня предупредили, что SVN не особенно удобен для больших двоичных файлов. Я опасаюсь попробовать это, чтобы увидеть, работает ли это, так как они всегда будут в истории репозитория, даже если я позже удалю их.
Есть альтернативы? Нам понадобится возможность комментировать и / или помечать документы, но мы можем использовать сервис, похожий на Delicious, в сочетании с URL-адресами для документов в SVN (или аналогичных).
Позже я не очень беспокоюсь о различиях в двоичных файлах, поскольку, как указано выше, они не сильно изменятся. У меня все в порядке с небольшими хлопотами, если они это сделают - это не хуже, чем в SharePoint.
7 ответов
Существует разница между большим количеством больших двоичных файлов и большим количеством двоичных файлов.
По моему опыту, SVN подходит для отдельных двоичных файлов размером в несколько сотен мегабайт. Единственные проблемы, которые я видел, начинают возникать с отдельными файлами размером около гигабайта или около того. Операции не выполняются по таинственным и неизвестным причинам, возможно, SVN не может решить проблемы, связанные с сетью.
Мне неизвестны какие-либо проблемы SVN, связанные с количеством двоичных файлов, за исключением отсутствия у них возможности объединения и того факта, что двоичные файлы часто не могут быть эффективно сохранены как дельты (SVN может использовать дельты).
Так;
- 1000 1 МБ файлов = отлично.
- 100 10 МБ файлов = отлично
- 10 100 МБ файлов = отлично
- Файл 1 >1000 МБ = не очень хорошая идея.
Я надеюсь, что размер ваших документов вписывается в одну из прекрасных категорий:)
В моей предыдущей компании мы настраивали Subversion для хранения файлов САПР. Файлы до 100 МБ хранились в Subversion. Если многие люди "добавляют" большие файлы на веб-сервер Subversion, это может стать узким местом. Тем не менее, добавочные коммиты были в порядке.
Subversion хранит "бинарную дельту". Фактически, на стороне сервера двоичные и текстовые файлы обрабатываются одинаково при хранении "дельты". Проверьте раздел "Улучшения двоичного кодирования дельты" на странице http://subversion.tigris.org/svn_1.4_releasenotes.html. В нем явно сказано: "Subversion использует алгоритм xdelta для вычисления различий между строками байтов" (а не строки символов) ").
Просто для эксперимента я сохранил 10 версию САПР (файл детали CATIA). В каждой версии я вносил небольшие изменения в детали, а затем проверял размер хранилища на стороне сервера. Общий размер был около 1,2х для 10 ревизий (х - исходный размер файла).
Не забудьте установить свойство svn:needs-lock. По моему опыту, лучший способ - использовать 'auto props', чтобы установить svn:needs-lock на основе расширения файла.
Именно для этого мы и создали наш клиент Subversion, так как выполняли действительно большие дизайнерские / консалтинговые работы, которые действительно требовали контроля версий. У нас никогда не было проблем с этим.
Это зависит от того, как часто файлы обновляются. Он ничего не может сделать для слияния бинарных файлов, поэтому каждый раз, когда возникает конфликт, вам будет больно. В противном случае это просто хранение и извлечение, и хотя оно не так хорошо, как с текстом, оно все равно прекрасно справляется.
Я лично использую Mercurial для таких задач. Я использовал его для хранения нескольких сотен концертов медиа. Да, это занимает некоторое дисковое пространство, но дисковое пространство дешево. С Mercurial вы также получаете выгоду от его распространения, поэтому, выполняя "проверку" или клонирование, как известно в Mercurial, вы получаете весь репо, а не просто снимок. Если ваш сервер когда-нибудь умрет, значит, вы все еще в бизнесе.
Из того, что я видел, Git очень быстр по сравнению с Subversion, и я слышал, что он несколько быстрее, чем Mercurial, но лишь немного. Однако я специально не тестировал его с большими или большим количеством двоичных файлов.
Учитывая то, как Git отслеживает изменения, я думаю, что он очень эффективен при работе с двоичными файлами.
Я могу сказать это точно, хотя; Как только я привык к Git, я никак не мог вернуться к Subversion. Когда мне приходится работать с репозиториями Subversion, я все еще использую Git, хотя git-svn. Таким образом, я получаю все преимущества распределенного управления версиями, но все равно получаю хорошую поддержку для отправки коммитов обратно в центральное хранилище Subversion.
Ну, это займет много места для хранения всего этого в Subversion, я вам очень расскажу. Subversion не хранит двоичные файлы через дельту так, как хранит текстовые файлы. Это, вероятно, займет столько же места, сколько и просто для хранения нескольких двоичных файлов на вашем жестком диске плюс хранилище.
Вы можете быть в состоянии на стороне сервера tiddlywiki для хранения URL-адресов документов в Subversion.
Если это в основном файлы.doc и.xls, есть также Microsoft Sharepoint.