Я удивлен тем, сколько времени требуется, чтобы объединить очень маленькое изменение из любой конкретной ветви в ствол; 1-2 минуты, чтобы объединить несколько строк текста, которые изменились в одном текстовом файле длиной всего 2 КБ.
Я хотел бы, если возможно, сделать слияние намного быстрее, но не знаю, с чего начать. Я сделал быстрый Google, и возможные причины медленного слияния, кажется, включают в себя любое из следующих действий: -
- Большой размер репо (как с точки зрения размера на диске, так и количества ревизий).
- Большое исходное дерево (по-видимому, SVN должен ползти по дереву, чтобы отработать изменения)
- Версия SVN сервера / клиента
- Очень большие (несколько МБ) файлы (у нас нет очень больших отдельных файлов, поэтому я сомневаюсь, что это повлияет на нас)
Полагаю, я действительно хочу знать, как выяснить, какие из вышеперечисленных пунктов делают слияния настолько медленными.
Прямо сейчас я в неведении относительно того, что работа с клиентом или работа на сервере занимает больше всего времени (ну, я подозреваю, что это клиент, так как загрузка сервера невелика на сервере). Я действительно думал, что это может быть огромное количество сведений о слиянии, которое накопило более 100 слияний, но я провел тест, в котором я удалил всю информацию о слиянии из нескольких ветвей, а затем выполнил слияние и обнаружил такую же медленность.
Так что я хотел бы спросить:
* Как можно провести диагностику / профилирование активности SVN?
* Основываясь на приведенной ниже информации, есть ли что-то действительно очевидное, что приведет к снижению производительности?
Спасибо
Chris
Вот некоторые факты / цифры о нашей настройке SVN
- В нашем репозитории SVN содержится около 32000 ревизий.
- Размер репо на диске: 8,3 ГБ
- Каждая из наших ветвей разработки имеет около 1400 версионных папок (19000 версионных файлов)
- Сервер SVN: 1.6.6 (r40053) (размещен в Apache, работающем на Ubunto Lucid Lynx)
- Я использую черепаху 1.6.9 на Win7 (хотя другие члены команды используют SmartSVN и сообщают о такой же скорости).
Редактировать
Возможно, стоит добавить, что когда мы разветвляемся / сливаемся, мы разветвляемся из ствола и всегда объединяем всю ветвь обратно в ствол. Таким образом, вся информация merge находится в папке соединительных линий (и ветвей).
Выводы
В моем случае это был доступ к диску, который был узким местом в процессе слияния - когда я переместил дерево исходных текстов с жесткого диска на твердотельный накопитель, то же слияние изменилось с 50 +/- 5 с до 7 + / - 1с.
Наблюдение за черепаховым процессом SVN в проводнике процессов во время слияния было весьма показательным: во время слияния с моим жестким диском байты ввода-вывода составляли от 500 кбит / с до 3 Мбит / с в течение большей части времени. На SSD байты ввода / вывода были до 10-20 Мбит / с. [Скорее, некоторые слияния на моем жестком диске имели сопоставимую скорость (и байты ввода-вывода были такими же высокими), как и на моем SSD - в этих случаях я предполагаю, что многие читаемые файлы уже находились в файловом кеше Windows ].
Я нашел следующие все увеличенные скорости слияния
- Слияние из & в папку глубже в исходной иерархии: для нас это не вариант в «реальной жизни», потому что отслеживание слияния становится практически невозможным, если не записано в папку «магистральный уровень», но показывает что слияние гораздо меньших деревьев делает процесс намного быстрее.
- Уменьшение размера объединяемого рабочего набора в подсказки (при условии, что вы используете опцию слияния глубины «рабочий набор», а не полностью рекурсивную), поэтому простое удаление папок (из моего рабочего набора под транком) увеличило скорость .