Если вам нужно много параллельных разработок, вам нужно использовать распределенную систему контроля версий, ClearCase или Perforce. ClearCase и Perforce не осуществляют распределенный контроль версий, но они обрабатывают слияния, вероятно, лучше, чем большинство других инструментов.
Слияние ClearCase предназначено для параллельной разработки и работает очень хорошо. Фактически, большинство разработчиков в ClearCase разрабатывают свои собственные ветви, а затем объединяют свои изменения в интеграционный поток , когда работа над ними завершена. Слой UCM поверх ClearCase просто автоматизирует это поведение.
Объединение Perforce более приспособлено к тому, что они называют расходящимся ветвлением , но, похоже, хорошо справляется с параллельной разработкой.
Subversion - отличная система контроля версий. Я часто его использую, и вы не можете превзойти цену, но давайте посмотрим правде в глаза, объединение в Subversion все еще очень, очень грубое по краям. Использование свойств для отслеживания слияния очень хакерское. Когда вы просматриваете журналы, вы видите множество изменений просто из-за того, что Subversion изменила свойство svn: merge, хотя файлы в основном не были затронуты. Кроме того, вы должны знать, когда следует использовать флаг --reintegrate.
Конечно, распределенные системы контроля версий обрабатывают параллельную разработку с помощью aplomb. Это то, как они были разработаны с самого начала.
Мой единственный вопрос: почему вы делаете так много параллельных разработок? За эти годы я обнаружил, что принуждение разработчиков к совместной работе над одним и тем же набором изменений просто работает лучше всего. Когда они вынуждены работать над одним и тем же набором кода, разработчики более осторожны в их разработке. Они берут укусов , более осторожны с изменениями и больше общаются друг с другом.
Когда я работал с разработчиками в ClearCase, и у каждого разработчика была своя ветвь, я использовал, чтобы обойтись и убедиться, что разработчики регулярно объединяют свои изменения. Программировать намного проще, когда никто, кроме вас, не меняет код. Разработчики просто делали всю свою работу в своей ветке, не получая изменений, внесенных другими разработчиками. У вас есть все 20 разработчиков, и вы не видите никаких изменений в основной ветке. Затем, непосредственно перед доставкой, разработчики должны были сделать массивные слияния всех своих изменений. Веселье последовало.
Мы потратили бы следующую неделю, пытаясь все очистить и заставить все изменения разработчика работать вместе. QA был расстроен, потому что у них почти не было времени на тестирование. Нередко отправлять релиз не тестировали. В конце концов, мы должны были уложиться в сроки.
Есть веские причины для одновременной разработки, но я обнаружил, что разработчики часто просят об этом, потому что это облегчает их работу. Им не нужно координировать свои изменения, потому что теперь это ваша работа. В конце концов, именно поэтому они платят вам большие деньги.
Ну, не очень большие деньги, но вам платят больше, чем многим людям. Может быть, не разработчики, но вы делаете больше, чем другие люди в вашей компании, как уборщик - если он не входит в профсоюз. Ну, вы получаете опционы на акции.