Представление StarTeam / подход ветвления - PullRequest
Новая
       32

Представление StarTeam / подход ветвления

3 голосов
/ 12 февраля 2009

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

Я думаю, вы захотите сделать что-то вроде этого: 

->Main branch (1.0)
-->Cust #1 Release (1.1)
-->Cust #2 Release (1.2)

После завершения 1.1 вы должны объединить этот код с 2.0. То же самое для 1.2. Тогда вы создадите 2.1 или 2.2.

Имеет ли это смысл? Нужно просто найти решения для управления конфигурацией, основанные на здравом смысле, которые подойдут для нашего сценария и будут легко работать со StarTeam.

Спасибо.

Обновление : я нашел ST руководство по наилучшим практикам , которое содержит полезную информацию по этому вопросу (см. Главу 5). Рекомендации соответствуют использованию Craig ST (см. Ниже). Обратите внимание, что это руководство было опубликовано в декабре 2003 года.

1 Ответ

4 голосов
/ 12 февраля 2009

Возможно, вы не захотите это слышать, но нет лучшего способа. Сказав это, я скажу вам, что мы делаем.

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

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

  1. Единственное, что изменилось в этом файле, - это исправление ошибки или функция, которую мы хотим использовать как в версии, так и в следующей версии.
  2. В файл были внесены изменения, которые предполагается включить в следующую версию, но не в версию, которая будет выпущена.

В случае (1) мы переходим в производное представление, щелкаем правой кнопкой мыши по файлу, выбираем Advanced-> Behavior и изменяем конфигурацию так, чтобы файл включал только что сделанные нами изменения. В случае (2) мы проверяем файл в представлении по умолчанию (чтобы изменения были включены в следующую версию) и в производное представление (чтобы изменения были включены в версию, которая будет выпущена, и , конечно, только включая эти изменения), вызывая его ветвление.

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

Это не слишком далеко от того, что вы предлагаете сделать для своих клиентов, но важным моментом является работа в представлении по умолчанию и во избежание необходимости выполнять массовые слияния вверх или вниз в производных представлениях. Инструмент сравнения / слияния StarTeam просто не так хорош. (Мы используем 2005 год; с тех пор он мог улучшиться.)

...