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

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

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

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

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


content-management-system documentation svn
person Community    schedule 11.02.2009    source источник

Ответы (7)


arrow_upward
33
arrow_downward

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

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

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

So;

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

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

person Community    schedule 11.02.2009
comment
Я надеялся, что это различие верно, но не был уверен. - person James A. Rosen; 12.02.2009
comment
Судя по другим ответам, тот факт, что ревизии не хранятся в виде дельт, не соответствует действительности. Не могли бы вы изменить это? - person onnodb; 14.02.2009
comment
для хранения файлов требуется много оперативной памяти, поэтому, возможно, ваш веб-сервер отказывается (если обслуживается через Apache). Я знаю, что раньше у меня возникали ошибки с моей маленькой виртуальной машиной, они появлялись после того, как я выделял больше оперативной памяти. Новые версии, видимо, будут лучше. - person gbjbaanb; 27.09.2010

arrow_upward
40
arrow_downward

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

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

Просто для эксперимента я сохранил версию 10 CAD (файл детали CATIA). В каждую версию я вносил небольшие изменения в часть, а затем проверял размер репозитория на стороне сервера. Общий размер был примерно в 1,2 раза больше для 10 ревизий (x - исходный размер файла).

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

person Community    schedule 14.02.2009

arrow_upward
3
arrow_downward

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

person Community    schedule 14.02.2009

arrow_upward
1
arrow_downward

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

person Community    schedule 11.02.2009

arrow_upward
0
arrow_downward

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

person Community    schedule 11.02.2009
comment
Быстрый вопрос: как вы справляетесь с клонированием многогигабайтных репозиториев каждый раз, когда вам нужно создать новую рабочую копию? - person David Suarez; 27.04.2011

arrow_upward
-4
arrow_downward

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

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

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

person Community    schedule 11.02.2009
comment
Я большой поклонник Git, но у нас уже есть инфраструктура SVN, а для Git у нас ее нет. Если SVN не заработает, так тому и быть, а если заработает, возьму халявную админку! - person James A. Rosen; 12.02.2009
comment
Это прямой вопрос: что такого хорошего в Git? - person Peter Wone; 01.04.2009
comment
Вместо того, чтобы пытаться объяснить это здесь. Посмотрите это очень самоуверенное выступление создателя Git. youtube.com/watch?v=4XpnKHJAok8 Да, это самоуверенно, но я согласен с мнением. Все, что я могу сказать, это дать ему реальный шанс. Хотя бы пару недель. И ты поймешь. - person Robert Walker; 02.04.2009
comment
Попробуйте рассказать нам, каково это на самом деле с двоичными файлами, не воображая, на что это могло бы быть похоже. Я могу себе представить, что git вообще не работает с файлами Microsoft - это было бы таким же глупым утверждением, как и ваш «ответ». - person gbjbaanb; 27.09.2010
comment
В моем случае svn работал лучше, чем git. Я работал над очень большим веб-проектом php, в котором было много двоичных файлов, разбросанных по каталогам. svn small checkout работал очень хорошо с нами. Git sparse checkout не работал, потому что stackoverflow.com/questions/11214295/ - person surajz; 06.07.2012
comment
Для использования Git с большими двоичными файлами вам следует проверить расширение хранилища больших файлов Git, которое теперь доступно. - person Kuitsi; 25.07.2016
comment
Git хорош для текстовых файлов, но определенно не очень хорошо обрабатывает двоичные файлы. - person Wei Qiu; 21.08.2020

arrow_upward
-5
arrow_downward

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

Вы можете использовать tiddlywiki на стороне сервера для хранения URL-адресов документов в Subversion.

Если это в основном файлы .doc и .xls, есть еще Microsoft Sharepoint.

person Community    schedule 11.02.2009
comment
Вы правы, сэр, это большая проблема, с которой мы сталкиваемся на работе. Выпускаются и другие системы управления версиями, которые работают с двоичными файлами И дельтами. - person Kezzer; 11.02.2009
comment
С SharePoint было бы сложно хотя бы потому, что мне потребовались бы недели, чтобы загрузить все эти файлы по отдельности. - person James A. Rosen; 12.02.2009
comment
Хм? Одним из основных преимуществ Subversion по сравнению с CVS является то, что Subversion ДЕЙСТВИТЕЛЬНО делает изменения в двоичных файлах. - person Andy Dent; 13.02.2009
comment
Возможно, что-то изменилось с тех пор, как я начала им пользоваться. Можете ли вы указать мне на некоторые документы об этом? Спасибо, Энди! - person leeand00; 13.02.2009
comment
@ leeand00: Вот статья, в которой рассказывается о хранилище SVN. ibm.com/developerworks/java/library/j-svnbins.html< /а> - person Bill the Lizard; 21.05.2009
comment
Уже поздно .. Но для других читателей здесь задокументирована Дельта двоичных файлов: svnbook.red-bean.com/en/1.6/svn.forcvs.binary-and-trans.html - person Spangen; 31.03.2016