Как я могу ускорить обновления SVN?

Question

У нас довольно большой SVN-репозиторий. Обновление SVN занимает все больше и больше, чем больше мы добавляем код. Мы добавили svn:externals в папки, которые повторялись в некоторых проектах, таких как FCKeditor на различных веб-сайтах. Это помогло, но не так сильно.

Как лучше всего сократить время обновления и увеличить скорость SVN?

Answer 1

Если это более старый SVN-репозиторий (или даже совершенно новый, но не настроен оптимально), возможно, он использует более старый стиль базы данных репозитория BDB. http://svn.apache.org/repos/asf/subversion/trunk/notes/fsfs имеет заметки о новом. Переход от одного к другому не слишком сложен - выгрузите всю историю, заново инициализируйте ее с новым форматом файловой системы svn и повторно импортируйте. В то же время может быть полезно отфильтровать репо-дамп, чтобы удалить все проверки бесполезной информации (например, я удалил 20 МБ + тарбол-файлы, которые кто-то зарегистрировал).

Что касается общей скорости, то качественный (скоростной) жесткий диск и дополнительную память для кэширования на базе ОС будет сложно определить с точки зрения увеличения скорости работы SVN.

На стороне клиента, если вы настроили tortoisesvn через PuttyAgent для доступа по SSH к внешнему компьютеру хранилища, вы также можете включить сжатие SSH, что также может помочь.

Редактировать: В SVN v1.5 также есть инструмент fsfs-reshard.py , который может помочь разбить svn-репозиторий на основе FSFS на несколько каталогов, которые сами могут быть связаны на разные приводные шпиндели. Если у вас есть тысячи ревизий, это также может помочь - если по какой-либо другой причине поиск одного файла среди тысяч занимает время (и вы скажете, если это проблема, посмотрев время IOwait)

Answer 2

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

Answer 3

Не совсем ответ, но может быть интересно знать, что одна из причин, по которой svn так требовательна к вводу / выводу, заключается в том, что он хранит одну дополнительную копию каждого файла в каталоге .svn / text-base. Это ускоряет локальные операции сравнения, но затрачивает много места на жестком диске и ввод / вывод.

http://subversion.tigris.org/issues/show_bug.cgi?id=525 имеет подробную информацию.

Answer 4

Похоже, у вас есть несколько проектов в одном хранилище. Разделение их там, где это уместно, даст вам большой импульс.

Предположительно, Git намного быстрее, чем Subversion, из-за того, как он хранит / обрабатывает изменения, но у меня нет опыта из первых рук.

Answer 5

Убедитесь, что ваше соединение с сервером является быстрым, насколько это возможно (гигабитный Ethernet). Убедитесь, что на сервере есть быстрые диски в массиве. И, конечно, только проверить, что вам нужно.

Answer 6

Есть несколько распространенных настроек производительности. SVN очень тяжелый ввод / вывод, поэтому более быстрые жесткие диски являются опцией (на обоих концах). Добавьте больше памяти на ваш сервер. Убедитесь, что у ваших клиентов дефрагментированный жесткий диск (для Windows).

Какой метод доступа вы используете, также имеет значение. Хранилища, хранящиеся в удаленных файловых системах (с использованием file: /// access), будут работать намного медленнее, чем svnserve или Apache с mod_svn. Рассмотрите возможность использования одного из последних, если у вас есть репозиторий на простом общем файловом ресурсе.

Answer 7

Иногда медленная работа SVN, особенно со многими внешними устройствами, связана с DNS. Похоже, что SVN выполняет поиск DNS для каждого SVN: внешнего, даже для относительных. Добавление имени хоста вашего сервера SVN в / etc / hosts или исправление resolv.conf может быть полезным.

Answer 8

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

Answer 9

Использование прав доступа на чтение (то есть ограничение доступа на чтение для определенных лиц / групп) сильно замедлит работу хранилища. Особенно, когда аутентификация выполняется каким-то особым образом, например, против домена Windows. Конечно, то же самое относится и к правам доступа на запись, но запись происходит реже, чем чтение. И ограничение доступа на запись может быть более важным, чем ограничение доступа на чтение

Answer 10

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

• скрипт сборки верхнего уровня запускает все скрипты сборки модулей
• внешние библиотеки не хранятся в Subversion, а извлекаются из сетевого диска с использованием Apache Ivy. (думайте об этом как о внутреннем хранилище Maven).
• зависимости между модулями также управляются с помощью Ivy.

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