Рефакторинг за несколько ветвлений с большим количеством изменений структуры каталогов - PullRequest
1 голос
/ 28 августа 2011

Существует очень большое решение Visual Studio (почти 200 проектов), которое мне нужно реорганизовать и реструктурировать, объединить и, возможно, разделить многие из этих проектов, изменить код ...

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

Вопрос в том - разумно ли полагаться на SVN для объединения проектов в будущем или мне нужен внешний инструмент?Или, возможно, пишу свой собственный инструмент.

Извините за основной вопрос, я относительно новичок в SVN и не уверен, что это лучший путь.

1 Ответ

2 голосов
/ 29 августа 2011

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

Насколько я помню, выполнение таких действий приводит к тому, что разработчики тратят около 1/4, если не 1/3, времени на исправление ошибок регрессии, вызванных слиянием SVN (эти оценки получены из JIRA ).

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

Наш выход из этого беспорядка заключался в изменении стратегии ветвления (ищите в Интернетечто-то вроде стратегия ветвления контроля версий , если вам интересно).Стратегия, на которую мы изменили, была нестабильный ствол (это также термин с возможностью поиска в случае, если вам интересно).Это переключение потребовало довольно заметных усилий для подготовки и некоторых изменений в процессе разработки (подробнее об этом ниже), но в целом результат оказался более чем удовлетворительным - IIRC уровень отходов снизился более чем в 4 раза.

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

... или мне нужен внешний инструмент?

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

Тогда я был достаточно доволен тем, что у нас было, поэтому я не пометил, какой инструмент он упоминал.Хотя в SO, похоже, много дискуссий, например:
- Какой самый лучший трехсторонний инструмент слияния?
- Инструменты для объединения SVN
- Лучший инструмент слияния для Subversion


PS.И независимо от того, как вы решаете проблемы со слиянием, было бы очень полезно иметь всеобъемлющий и простой в использовании набор тестов

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...