Создание branch в CVS?
Voituk Vadim
В CVS-репозитории лежит проект X.
Для каждого из заказчиков в проект
вносятся изменения. Тоесть у каждого
из них своя версия, что отличается от
базовой, специфичными для этого
заказчика изменениями.
Хотелось бы эти дополнительные версии
хранить тоже в CVS и по мере
необходимости выполнять merge для
некоторых их изменений в главную
версию, и наоборот - из главного
добавлять изменения в дополнительные.
Подскажите как такое организовать.
Желательно бы на простеньком примере,
потому что идиологии я до конца не
понимаю.
--
Respecfully Voituk Vadim
icq#944328
Alexander Ogol
Желательно всё же избавляться от версионирования кода под разных клиентов.
Выносить всё в параметры приложения.
Если причина версионирования - фичи, реализованные конкретному клиенту за
доп. плату - просто усложнять возможность включения фичи клиентам, которые
за неё не платили, но поставлять им полные версии.
Идея в следующем: если клиент срочно захотел какое-то изменение, и вы его
сделали на бранче, заточенном для клиента, сразу же реализуйте ту же
функциональность и на транке. Возьмите себе за правило: транк должен всегда
содержать всю функциональность, что есть на каких-то бранчах. Так - не
запутаетесь.
Если клиент захотел изменение не срочно, то реализуйте функциональность на
транке, а клиенту предлагайте перейти на последнюю стабильную версию в той
release line, что стоит у клиента.
Если транк уже ушёл далеко вперёд, и изменение настолько серьёзное, что его
нельзя портировать в тот release line, которым пользуется клиент,
предлагайте ему сапгрейднуться по скидочным ценам на нужный release line.
Thank you!
Voituk Vadim
Alexander Ogol писал(а):
> Привет,
> Желательно всё же избавляться от версионирования кода под разных клиентов.
> Выносить всё в параметры приложения.
> Если причина версионирования - фичи, реализованные конкретному клиенту за
> доп. плату - просто усложнять возможность включения фичи клиентам, которые
> за неё не платили, но поставлять им полные версии.
>
> Идея в следующем: если клиент срочно захотел какое-то изменение, и вы его
> сделали на бранче, заточенном для клиента, сразу же реализуйте ту же
> функциональность и на транке. Возьмите себе за правило: транк должен всегда
> содержать всю функциональность, что есть на каких-то бранчах. Так - не
> запутаетесь.
>
> Если клиент захотел изменение не срочно, то реализуйте функциональность на
> транке, а клиенту предлагайте перейти на последнюю стабильную версию в той
> release line, что стоит у клиента.
>
> Если транк уже ушёл далеко вперёд, и изменение настолько серьёзное, что его
> нельзя портировать в тот release line, которым пользуется клиент,
> предлагайте ему сапгрейднуться по скидочным ценам на нужный release line.
Спасибо, очень дохдчиво пояснил.
В принципе так все и понимаю.
Но вот как реализовать несколько веток
и как их сливать в одни и во вторую
сторону - не знаю, потому и прошу пример
простенький.
А как например делать для web-проекта
для какого меняется только дизайн для
каждого заказчика? (ну и иногда
мелочные доработки а-ля "подсвечивать
каждую вторую строку в таблице")
Alexander Ogol
> Спасибо, очень дохдчиво пояснил.
> В
принципе так все и понимаю.
> Но вот как реализовать несколько
веток
> и как их сливать в одни и во вторую
> сторону - не знаю,
потому и прошу пример
> простенький.
Можно пользоваться 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
Alexander Ogol
ЧТО нужно делать, чтобы получить результат...
Вон, процесс разработки ядра FreeBSD в корне отличается от того, что я
написал.
Правда, у них специфика совсем другая.
Thank you.
