Что определяет скорость операции слияния SVN 1.6

Я удивлен, сколько времени требуется, чтобы объединить очень небольшое изменение из любой конкретной ветви в ствол; 1-2 минуты, чтобы объединить несколько строк текста, которые были изменены в один текстовый файл длиной всего 2 КБ.

Я бы хотел, если возможно, сделать объединение чертовски быстрее, но не знаю когда начать. Я быстро погуглил, и возможные причины медленного слияния, похоже, включают все без исключения следующие: -

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

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

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

Итак, я хотел бы спросить: -

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

Итак, я хотел бы спросить: -

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

Итак, я хотел бы спросить: - * Как подойти к диагностике / профилированию активности SVN? * Основываясь на информации ниже, есть ли что-то действительно очевидное, что может вызвать низкую производительность?

Спасибо

Крис

Вот некоторые факты / цифры о нашей настройке SVN

• В нашем репозитории SVN их около 32000 версии.
• Размер репо на диске: 8,3 ГБ
• В каждой нашей ветке разработки есть около 1400 папок с версиями (19 000 файлов с поддержкой версий)
• Сервер SVN: 1.6.6 (r40053) (размещен в Apache, работающем на Ubunto Lucid Lynx )
• Я использую tortoise 1.6.9 на Win7 (хотя другие члены команды используют SmartSVN и сообщают о той же скорости).

Править

Возможно, стоит добавить это при ветвлении / слиянии , мы ответвляемся от ствола и всегда объединяем всю ветвь обратно в ствол. Таким образом, вся информация mergeinfo находится в папке основной (и ветвей).

Выводы

В моем случае Наблюдение за процессом SVN черепахи в проводнике процессов во время слияния было весьма показательным: во время слияния на моем жестком диске байты ввода-вывода находились в диапазоне от 500 кб / с до 3 Мб / с большую часть времени. На SSD байты ввода-вывода были до 10-20 Мбит / с. [Скорее сбивает с толку, некоторые слияния на моем жестком диске имели сопоставимую скорость (и байты ввода-вывода были одинаково высоки), как и на моем SSD - в этих случаях я предполагаю, что многие из читаемых файлов уже были в файловом кеше Windows ].

Я обнаружил следующее: увеличенная скорость слияния

• Слияние из и в папку на более глубоких уровнях иерархии источников: это не вариант для нас в «реальной жизни», потому что отслеживание слияния становится почти невозможным, если не записывается в папку «магистрального уровня», но показывает, что слияние гораздо меньших деревьев значительно ускоряет процесс.
• Уменьшение размера объединяемого рабочего набора, чтобы помочь (при условии, что вы используете параметр слияния по глубине «рабочий набор», а не полностью рекурсивный) - поэтому простое удаление папок (из моего рабочего набора в основной строке) увеличивает скорость .