> Спасибо, очень дохдчиво пояснил.
> В принципе так все и понимаю.
> Но вот как реализовать несколько веток
> и как их сливать в одни и во вторую
> сторону - не знаю, потому и прошу пример
> простенький.
Можно пользоваться 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 век. Туда же - мейлеры, которые
его не поддерживают.
|
