Как я могу одновременно работать с версиями 1.1 и версией 2.0?

Ситуация: мы вышли из бета-версии, а версия 1.0 была выпущена на несколько клиентских сайтов. Команда A уже занята работой над версией 1.1, которая будет иметь инкрементные исправления и юзабилити, а другая команда работает с версией 2.0 с крупномасштабными изменениями, где ядро продукта может быть полностью переработано. Теперь большинство изменений, сделанных для версии 1.1, в какой-то момент должны пробиться в 2.0, и некоторые исправления ошибок, сделанные в ветке 2.0, возможно, должны быть запланированы для более ранней версии. Проблема в том, что, поскольку 2.0 имеет фундаментальные различия, никакие изменения от 1.1 не могут быть объединены без ручного преобразования, и наоборот.

Мой вопрос: Каковы наилучшие методы контроля версий, чтобы минимизировать конфликты слияния и дублировать работу в подобной ситуации? Как я могу обеспечить, чтобы мои команды тратили как можно меньше времени на усилия по контролю версий, но при этом регулярно предоставляли клиентам исправления?

Ответ 1

Один хороший способ - исправить каждую ошибку в устойчивой ветки и объединить стабильную ветвь в ветку разработки. Это Parallel Maintenance/Development Lines, и ключ состоит в том, чтобы объединиться рано и часто. Слияние нечасто и поздно означает, что ветвь развития неузнаваема по сравнению со стабильной, или ошибка не может повторяться одинаково.

Subversion включает отслеживание слияния с версии 1.5, поэтому вы гарантируете, что один и тот же набор изменений не будет объединен дважды, что приведет к глупым конфликтам. Существуют и другие системы (например, Git, Mercurial, Accurev, Perforce), которые позволяют делать запросы типа "какие изменения на ветке A не были объединены в ветвь B?" и вишня - выберите исправления, которые вам нужны, в ветвь dev.

Ответ 2

В статье здесь (изо дня в день с Subversion) упоминается, что одним из методов является постоянное обновление версии 2 с данными из версии 1.1 build. В статье парень говорит, чтобы делать это каждый день.

Часть, которую вы хотите прочитать, называется "Официант, там ошибка в моей сундучке!". Это примерно на полпути, хотя статья.

Ответ 3

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

Ответ 4

В значительной степени то, что говорили все остальные, но я полагал, что буду использовать опыт разработки в нескольких ветвях, используя SVN

С нашим основным продуктом мы должны одновременно разрабатывать в версиях 2+.

Первоначально я использовал основную магистраль как версию "основной разработки" с тегами, используемыми для каждого фактического выпуска. Филиалы использовались для существенных усилий по разработке нового набора функций. Затем, когда мы начали работать над 2, 3 и 4 выпусками, я начал использовать ветвь для каждой ревизии.

Так как я поддерживаю репозиторий, а также обрабатываю pushing QA-сборки, я обязательно буду делать "свопы" каждое утро, которое состоит из слияния изменений дерева, начинающегося с самой низкой активной ветки. Таким образом, я заканчиваю слияние изменений с 1.1 на 1.2, который сливается с 1.3 с любыми другими изменениями из 1.2 с момента последнего слияния и т.д.

Когда я фиксирую, я всегда должен комментировать фиксацию с чем-то вроде

сливается 1.1 rev 5656-5690

Это может быть немного больно, но он работает:)

Ответ 5

Слизируйте на раннем этапе, часто объединяйтесь и убедитесь, что QA на магистрали знает и регрессирует/проверяет дефекты, зафиксированные в каждом патче релизов обслуживания.

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

Убедитесь, что вы используете систему управления версиями, которая поддерживает ветвление и слияние (у меня был опыт работы с Perforce и SVN, а в то время как Perforce лучше, SVN является бесплатным).

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

Ответ 6

Как мы справляемся с этим на моей работе, нужно сохранить ветвь соединительной линии как самый передовой код (т.е. 2.0 в этом случае). Вы создаете ветку для кода 1.x и делаете все свои исправления. Любые изменения в 1.x должны быть объединены (если необходимо, вручную) в ветку соединительной линии (2.0).

Тогда я настаивал бы на том, чтобы 1.x разработчики отмечали как номер версии для фиксации 1.x, так и номер версии для слияния 2.0 в билете для этой ошибки. Таким образом, будет легче заметить, если кто-то забывает объединить свои изменения, и тот факт, что они должны отслеживать это, поможет им запомнить.

Ответ 7

Один ключевой момент зафиксирован в этот рисунок от The Build Doctor: только объединить одно направление.

Ответ 8

Чтобы ответить на этот конкретный вопрос, многие разработчики переключились с Subversion на Git. Оформить заказ github.com.