Создание branch в CVS?

11 views
Skip to first unread message

Voituk Vadim

unread,
Aug 19, 2005, 10:24:14 AM8/19/05
to ua-devtalk
Добрый день, All
В CVS-репозитории лежит проект X.
Для каждого из заказчиков в проект
вносятся изменения. Тоесть у каждого
из них своя версия, что отличается от
базовой, специфичными для этого
заказчика изменениями.
Хотелось бы эти дополнительные версии
хранить тоже в CVS и по мере
необходимости выполнять merge для
некоторых их изменений в главную
версию, и наоборот - из главного
добавлять изменения в дополнительные.

Подскажите как такое организовать.
Желательно бы на простеньком примере,
потому что идиологии я до конца не
понимаю.

--
Respecfully Voituk Vadim
icq#944328

Alexander Ogol

unread,
Aug 19, 2005, 10:46:43 AM8/19/05
to ua-de...@googlegroups.com
Привет,
Желательно всё же избавляться от версионирования кода под разных клиентов.
Выносить всё в параметры приложения.
Если причина версионирования - фичи, реализованные конкретному клиенту за
доп. плату - просто усложнять возможность включения фичи клиентам, которые
за неё не платили, но поставлять им полные версии.

Идея в следующем: если клиент срочно захотел какое-то изменение, и вы его
сделали на бранче, заточенном для клиента, сразу же реализуйте ту же
функциональность и на транке. Возьмите себе за правило: транк должен всегда
содержать всю функциональность, что есть на каких-то бранчах. Так - не
запутаетесь.

Если клиент захотел изменение не срочно, то реализуйте функциональность на
транке, а клиенту предлагайте перейти на последнюю стабильную версию в той
release line, что стоит у клиента.

Если транк уже ушёл далеко вперёд, и изменение настолько серьёзное, что его
нельзя портировать в тот release line, которым пользуется клиент,
предлагайте ему сапгрейднуться по скидочным ценам на нужный release line.

Thank you!

Voituk Vadim

unread,
Aug 19, 2005, 10:53:42 AM8/19/05
to ua-devtalk

Alexander Ogol писал(а):

> Привет,
> Желательно всё же избавляться от версионирования кода под разных клиентов.
> Выносить всё в параметры приложения.
> Если причина версионирования - фичи, реализованные конкретному клиенту за
> доп. плату - просто усложнять возможность включения фичи клиентам, которые
> за неё не платили, но поставлять им полные версии.
>
> Идея в следующем: если клиент срочно захотел какое-то изменение, и вы его
> сделали на бранче, заточенном для клиента, сразу же реализуйте ту же
> функциональность и на транке. Возьмите себе за правило: транк должен всегда
> содержать всю функциональность, что есть на каких-то бранчах. Так - не
> запутаетесь.
>
> Если клиент захотел изменение не срочно, то реализуйте функциональность на
> транке, а клиенту предлагайте перейти на последнюю стабильную версию в той
> release line, что стоит у клиента.
>
> Если транк уже ушёл далеко вперёд, и изменение настолько серьёзное, что его
> нельзя портировать в тот release line, которым пользуется клиент,
> предлагайте ему сапгрейднуться по скидочным ценам на нужный release line.

Спасибо, очень дохдчиво пояснил.
В принципе так все и понимаю.
Но вот как реализовать несколько веток
и как их сливать в одни и во вторую
сторону - не знаю, потому и прошу пример
простенький.

А как например делать для web-проекта
для какого меняется только дизайн для
каждого заказчика? (ну и иногда
мелочные доработки а-ля "подсвечивать
каждую вторую строку в таблице")

Alexander Ogol

unread,
Aug 19, 2005, 1:13:03 PM8/19/05
to ua-de...@googlegroups.com

> Спасибо, очень дохдчиво пояснил.
> В принципе так все и понимаю.
> Но вот как реализовать несколько веток
> и как их сливать в одни и во вторую
> сторону - не знаю, потому и прошу пример
> простенький.

Можно пользоваться WinCVS - там всё визуально, и он пишет команды, потом можно пользоваться и консольным (тем более, в WinCVS не всё есть, и, в принципе, это логично - это же всего лишь оболочка).

Пример.. Он же технический получится. Ну ладно.. Авось пригодится.

Допустим, у нас 2 клиента: CL1 и CL2. На CL1 мы поставили свой софт раньше. CL2 нужен более продвинутый вариант, мы его ещё разрабатываем.

Процесс разработки такой (для простоты - опустим всякие переходы между папками, пусть есть один модуль src):
1. Релиз для CL1 - ставим тег. (кнопочка в WinCVS на тулбаре, в консоли cvs tag)

cvs co src
cvs tag PRJ1_0


2. Как только возникла необходимость саппорта релиза - забираем файлы по этому тегу, и делаем новый бранч (cvs tag -b)

cvs co -rPRJ1_0 src
cvs tag -b -B PRJ1_0
   (вот не помню, надо ли ещё что-то указывать. Новый релиз лайн делается редко)

С этого момента у нас есть фактически implementation line (транк) и release line (бранч).
3. Клиент CL1 попросил изменение. Сделали его на транке(1.c,v 1.3). Где можно - подняли бранчевый тег до нужной ревизии(тот же cvs tag), где нельзя - добавили ревизии на бранче. Например, пусть есть файл 1.c:

1.1 task1: common functionality    <- Branch Tag PRJ1_0
1.2 task2: functionality for CL2 (very serious changes)
1.3 task3: functionality for CL1

На версии 1.1 стоит тег PRJ1 - это то, что уже стоит у клиента CL1

cvs co -rPRJ1_0 src
cvs up -j1.2 -j1.3 1.c
<<<проверяем, что в 1.c действительно попали все изменения task3, и нет конфликтов Делаем то же для всех остальных файлов>>
cvs ci


В итоге получаем ревизию 1.1.2.1, помеченную тегом CL1.

Ещё раз: функциональность должна быть написана так, что CL2 не пострадает (настраиваемо в конфиг-файлах etc.).



> А как например делать для web-проекта
> для какого меняется только дизайн для
> каждого заказчика? (ну и иногда
> мелочные доработки а-ля "подсвечивать
> каждую вторую строку в таблице")

Я с веб-проектами не работаю, могу только предполагать, как лучше... Дизайн - это же такой же настраиваемый элемент, выбор дизайна тоже можно выделить в настройки (ini-файл и т.п.)
Возможно, для разных клиентов нужно будет собирать разные пакеты. Это - уже задача версионирования инсталляционного скрипта.

Мелочные доработки тоже желательно делать настраиваемыми. Пусть CL1 захотел подсветку каждой второй строки таблицы:
[Tables]
....
HighglightEverySecondLine=true
....

Изменений в коде будет совсем ненамного больше (разумеется, нужна хорошая обёртка над вашим хранилищем параметров):

if(evenLine) { if(evenLine && isOptionTrue("HighglightEverySecondLine")) {
  highlightCell();   highlightCell();
} }


Самое главное - это документировать абсолютно все изменения в багтрэкинге. Чтобы потом по описанию
"Task 12345: CL1 wants for every second line to be highlighted."
можно было легко понять, что это за задача, и стОит ли её ложить в release line. Из комментариев в багтрэкинге должно быть ясно, какие действия по загрузке надо провести, чтобы положить файлы на бранч.

 

 

PS: Sorry за HTML, если он в девтолке не принят. Обычно с ним нагляднее, а считать трафик на письмах - это - назад в 20 век. Туда же - мейлеры, которые его не поддерживают.

Alexander Prohorenko

unread,
Aug 19, 2005, 1:21:30 PM8/19/05
to ua-de...@googlegroups.com
По-моему в руководстве и так все описано.

http://ximbiot.com/cvs/manual/

Alexander Ogol

unread,
Aug 19, 2005, 1:38:24 PM8/19/05
to ua-de...@googlegroups.com
Вообще в руководстве есть описание, КАК делать, но ведь не всегда понятно,
ЧТО нужно делать, чтобы получить результат...
Вон, процесс разработки ядра FreeBSD в корне отличается от того, что я
написал.
Правда, у них специфика совсем другая.


Thank you.

Max Ischenko

unread,
Aug 20, 2005, 12:26:24 AM8/20/05
to ua-de...@googlegroups.com

Саша,

 

Я твое подробное объяснение выложил на вики, надеюсь ты не против.

 

Reply all
Reply to author
Forward
0 new messages