У нас есть довольно большой репозиторий SVN. Выполнение SVN-обновлений длится дольше и дольше, чем больше мы добавляем код. Мы добавили svn:externals в папки, которые были повторены в некоторых проектах, таких как FCKeditor на разных сайтах. Это помогло, но не так.
Каков наилучший способ сократить время обновления и повысить скорость SVN?
Если это более старый SVN-репозиторий (или даже совершенно новый, но не был настроен оптимально), возможно, он использует более старый стиль базы данных репозитория BDB. http://svn.apache.org/repos/asf/subversion/trunk/notes/fsfs содержит примечания к новой. Для перехода от одного к другому isn; t слишком сложно - сбрасывать всю историю, повторно инициализировать ее с новым svn файлом файловой системы и повторно импортировать. Также может быть полезно одновременно фильтровать репо-дамп для удаления целых проверок бесполезной информации (я, например, удалил файлы размером 20 МБ + tarball, которые кто-то зарегистрировал).
Что касается общей скорости - качественный (быстрый) жесткий диск и дополнительная память для кэширования на базе ОС будет трудно устранить с точки зрения увеличения скорости работы SVN.
На стороне клиента, если у вас есть установка tortoisesvn через PuttyAgent для доступа SSH к машине внешнего репозитория, вы также можете включить сжатие SSH, что также может помочь.
Изменить: В SVN v1.5 также есть инструмент fsfs-reshard.py, который может помочь разделить FSFS основанный на svn-репозитории в ряд каталогов, которые сами могут быть связаны с различными ведущими шпинделями. Если у вас тысячи изменений, это также может помочь - если не по какой-либо другой причине, чем найти один файл среди тысяч, требуется время (и вы скажете, если это проблема, посмотрев время IOwait)
Отключить проверку вирусов в папках, содержащих рабочий код. Это привело к тому, что мои обновления стали в два раза быстрее.
На самом деле это не ответ, но может быть интересно узнать, что одна из причин svn такова, что I/O-heavy - это тот факт, что он хранит одну дополнительную копию каждого файла в каталоге .svn/text-base. Это делает локальные операции diff быстрыми, но ест много пространства жесткого диска и ввода/вывода.
http://subversion.tigris.org/issues/show_bug.cgi?id=525 содержит сведения.
Похоже, у вас есть несколько проектов в одном хранилище. Разделение их по мере необходимости даст вам большой импульс.
Предположительно Git намного быстрее, чем Subversion из-за того, как он хранит/обрабатывает изменения, но у меня нет непосредственного опыта с ним.
Есть некоторые общие настройки производительности. SVN - очень тяжелый ввод-вывод, поэтому более быстрые жесткие диски являются опцией (с обоих концов). Добавьте больше памяти на ваш сервер. Убедитесь, что у ваших клиентов есть дефрагментированный жесткий диск (для Windows).
Какой метод доступа вы используете, также имеет значение. Хранилища, хранящиеся в удаленных файловых системах (с использованием файла:///access), будут намного медленнее, чем svnserve или Apache с mod_svn. Подумайте об использовании одного из последних, если у вас есть репозиторий на общем общем ресурсе файла.
Убедитесь, что ваше соединение с сервером выполняется быстро, как может быть (гигабитный ethernet). Убедитесь, что сервер имеет быстрые диски в массиве. И, конечно, только проверьте, что вам нужно.
TotoiseSVN по умолчанию рассматривает изменения файлов в фоновом режиме, и я видел, что это замедляет работу моей машины. Я изменил конфигурацию, чтобы исключить все, а затем включить только каталоги, в которых у меня есть выписки. Вы также можете отключить проверку фона. Обе эти настройки находятся в настройках "Наложение значков" node.
Я нашел в своем собственном опыте (то есть: не через какие-либо реальные тесты), что, особенно если сервер репо SVN удален, использование внешних ресурсов замедляет работу. Если у вас есть дублированный код (например, ваш редактор FCK) в нескольких местах, я бы склонен придерживаться внешних ресурсов, поскольку сохранение этих файлов синхронизировано и управляемо более важно, чем скорость обновления. Однако вы могли бы использовать символические ссылки для приведения в дублированном коде. (Если вы используете Windows XP, вы можете использовать точки соединения).
Мы разделили нашу базу кода на несколько модулей sibling и написали сценарии Ant, чтобы один разработчик мог работать на одном модуле за раз, не беспокоясь о том, что происходит в других модулях.
Как правило, разработчикам необходимо обновить все свое дерево пару раз в неделю, но это легко сделать, прежде чем отправиться на обед/кофе-брейк.
Использование прав доступа на чтение (т.е. ограничение доступа для чтения для определенных лиц/групп) значительно замедлит репозиторий. Особенно, когда аутентификация выполняется определенным образом, например, против домена Windows. То же самое справедливо и для прав доступа на запись, но запись менее частая, чем чтение. Ограничение доступа к записи может быть более важным, чем ограничение доступа для чтения.
Если у вас много папок в корневом каталоге репозитория, а ваша локальная копия отражает репозиторий, попробуйте разрезать монолитную локальную копию во многие разделенные загружаемые папки и обновлять эти папки отдельно, она будет действительно быстрее, чем одна большая папка.
Иногда медленная работа svn, особенно со многими внешними, связана с DNS. Похоже, svn выполняет поиск DNS на каждый svn: внешний, даже для относительных. Добавление вашего имени хоста svn-сервера в /etc/hosts или исправление resolv.conf может быть полезно.