Подскажите как такое организовать.
Желательно бы на простеньком примере,
потому что идиологии я до конца не
понимаю.
--
Respecfully Voituk Vadim
icq#944328
Спасибо, очень дохдчиво пояснил.
В принципе так все и понимаю.
Но вот как реализовать несколько веток
и как их сливать в одни и во вторую
сторону - не знаю, потому и прошу пример
простенький.
А как например делать для web-проекта
для какого меняется только дизайн для
каждого заказчика? (ну и иногда
мелочные доработки а-ля "подсвечивать
каждую вторую строку в таблице")
> Спасибо, очень дохдчиво пояснил.
> В
принципе так все и понимаю.
> Но вот как реализовать несколько
веток
> и как их сливать в одни и во вторую
> сторону - не знаю,
потому и прошу пример
> простенький.
Можно пользоваться 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 век. Туда же - мейлеры, которые его не поддерживают.