[cvs] Как убедить начальника?

CVS говно (c) Линус

>ибо не понимает зачем нужна отдельная ветка. Вот как-то так...

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

PS: Или вы что то не договариваете в вашей специфике.

начальник прав:

* он просто прекрасно отдает себе отчет в том, что вы задолбаетесь _контролируемо_ переносить изменения из одной ветки в другую (скажем, в продакшен ветке нашелся баг). если все тупо мерджить, ... тогда действительно, зачем еще одна ветка?

* начальник идеалист и верит что HEAD всегда компилируется и проходит все тесты. еще он верит в то, что HEAD всегда в любой момент можно отдать клиенту, т.к. код работоспособен

* от живет немного в ином мире, нежели вы

* ветки реально удобы, если вы бэкпортите функционал. а судя по проблеме, вы этого не делаете

* иной раз проще запомнить просто номер ревизии, отданой клиенту :)

А зачем нужна отдельная ветка для каждого заказчика? Из описания совсем не видно нужна она, или - нет.

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

Реализация этого с помощью CVS сулит мало хорошего. Mercurial (или другая система с подобными возможностями) подходит для решения намного лучше.

вообще говоря , отдельная ветка нужна не заказчику , а разработчику

> * начальник идеалист и верит что HEAD всегда компилируется и проходит все тесты. еще он верит в то, что HEAD всегда в любой момент можно отдать клиенту, т.к. код работоспособен

А ещё начальник, наверное, знает про тэги.

мой бывший начальник говорил, что ветки в CVS не нужны в принципе, даже при разработке большой фичи (командой из 15 человек). его пойнт был в том, что даже промежуточные результаты надо коммитить на head, а если вдруг надо вычекать рабочую версию, то для этого создаются цвсные метки. заставлять приводить полузакоммиченную кашу в чувства должен тот, кто сдает фичу, а контролировать, что это сделано правильно должен ревьювер по многокилобайтной портянке вывода cvs diff. к счастью, он больше не мой начальник :)

> а контролировать, что это сделано правильно должен

Автоматическая сборка и юнит-тесты.

>> а контролировать, что это сделано правильно должен

> Автоматическая сборка и юнит-тесты.

Ага, а еще тесты регрессий, интеграции и других умных слов. Моя мечта - это программный эмулятор юзеров разной степени тупости и злобности, для тестирования %)

"я не вижу абсолютно никакого смысла в ночных сборках" цитирую этого человека дословно. а юнит-тесты - это вообще что-то запредельное для его понимания

> Ага, а еще тесты регрессий, интеграции и других умных слов.

И ещё обязательно partner testing!

> Моя мечта - это программный эмулятор юзеров разной степени тупости и злобности, для тестирования %)

Можно тестерам выплачивать премии за найденные ошибки :)

> обязательно partner testing!

Partner compatibility testing - наше ффсио.

> Можно тестерам выплачивать премии за найденные ошибки :)

Но тестеров нельзя клонировать и запускать на кластере :/

> "я не вижу абсолютно никакого смысла в ночных сборках" цитирую этого человека дословно.

Ночные сборки часто только за некоторое время до релиза начинают делать, с какой-нибудь беты. Чтобы оперативно отлавливать сломанные фиксы.

> а юнит-тесты - это вообще что-то запредельное для его понимания

Тестирование - довольно дорогая затея. Может быть, штата тестеров нет, а программисты и так загружены. В России всё ещё должно было быть сделано вчера, как обычно.

> Но тестеров нельзя клонировать и запускать на кластере :/

Откройте офис в Китае. Очень дотошные и толковые ребята.

нет бы отвести бренч, а потом спокойно промержиться, вместо этого из обычного коммита нужно устраивать анальное рабство :)

> Ночные сборки часто только за некоторое время до релиза начинают делать, с какой-нибудь беты. Чтобы оперативно отлавливать сломанные фиксы.

в одной конторе, где я работал, ночные билды и ежедневное автоматизированное регрешн тестирование делали во время самого интенсивного девелопмента, а ближе к релизу код был уже более-менее вылизан и тестировались всего раза два в неделю

причина делать отдельную ветку только одна - коммитить туда хотфиксы.

> Дайте совет, как убедить начальника, что при сдаче очередной версии программы заказчику надо заводить отдельную ветку в CVS.

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

+1. Если нет необходимости поддерживать выпущенную версию (стабильную), ветки не нужны. Особенно такие кривые, как это сделано в CVS

> Если нет необходимости поддерживать выпущенную версию (стабильную)

Бгг. А правда бывает так, что "нет необходимости"? %)

Мне ни разу не попадалось. Но мало ль у кого какой бизнес;)

<offtopic><flame mode="on">Собственно говоря, а почему именно морально устаревший CVS а не тот-же SVN или даже GIT?</flame></offtopic>
Почитать раздел об ветках/тегах тут - http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
Тут все будет зависеть от начальника, бывают настолько упертые/недальновидные, что никаких аргументов не воспринимают.

Вы немного не поняли...

Заказчик один. Программа одна. Когда подходит срок, присваивается номер версии и сдаётся всё, что есть (и оно должно работать). Разработка идёт по плану, согласованом с заказчиком. Тем не менее бывают бэкпорты и фиксы. HEAD часто в несобираемом состоянии.

CVS потому что так сложилась жизнь ещё при царе Горохе. SVN, наверное, появится, потому что он уже на слуху, так сказать. А про более другие вещи тима mercurial начальник даже слышать не желает.

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

> Вы немного не поняли...
Ну дык в ТЗ было нечетко.

> Тем не менее бывают бэкпорты и фиксы.
Ну вот и все разъяснилось про Вашу задачу. Тогда я не понимаю, что Ваш начальник может иметь против. Как он себе представляет поддержку бэкпортов и фиксов?

> SVN, наверное, появится, потому что он уже на слуху, так сказать. А про более другие вещи тима mercurial начальник даже слышать не желает.
И не нужно ему DVCS, скорее всего. А переход на SVN безболезнен, привычки менять практически не придется.

Я думаю, разделение на trunk, branches, и tags уже вызовет недоумение...

>> про более другие вещи тима mercurial начальник даже слышать не желает.

> И не нужно ему DVCS, скорее всего.

Ему и ветки не нужны, да.

Смысл пытаться что-то объяснить что-то консервативному человеку? Он все-равно по-своему сделает наверняка.
Проще сделать в другом месте так, как Вы считаете правильным, а потом оказать и объяснить на конкретных примерах

SVN тебе в помощь

Ну, к этому привыкаешь за 5 минут. Если сама идея tags и branches в CVS есть, человек к ней привык - тут она просто "визуализирована".

Толсто.
DVCS вещь специфическая, намекает на концептуальный "апгрейд" процесса разработки. Тогда как для человека, привыкшего к CVS, модель разработки в SVN на 99.99 та же самая.

Сам я перетащил xkeyboard-config в git только для того, чтобы попробовать. Никакой реальной нужды в DVCS у меня не было (да я его и использую сейчас как испорченный CVS), причем многократно пожалел об этом переходе, ибо появилась куча сложностей, которые мне нафиг не нужны. Ну да, еще это был акт доброй воли по отношению к дистромейкерам - им стало чуть проще (про отношения с апстримом см. тред про дебиан и глибс:)

> Толсто.

Хочешь сказать, сабжевый начальник - тролль? Хм, интересная идея.

> DVCS вещь специфическая, намекает на концептуальный "апгрейд" процесса разработки

Нет. Она намекает на следование _естественным паттернам_ разработки, не втиснутым в прокрустово ложе CVS. Вспомни о quilt - это ни разу не DVCS, но я 90% времени я использую Mercurial как quitl на стероидах (и судя по тому, что я читаю, так делают многие; то же и с Git).

Хотя, если Прокруст успел отрубить ноги, тогда тяжело, да.

> я перетащил xkeyboard-config в git только для того, чтобы попробовать. Никакой реальной нужды в DVCS у меня не было (да я его и использую сейчас как испорченный CVS), причем многократно пожалел об этом переходе

Git вообще дерьмо^Wимеет неоправданно крутую курву обучения. Попробуй какую-ибудь надстройку типа StGIT.

> Она намекает на следование _естественным паттернам_ разработки, не втиснутым в прокрустово ложе CVS
Как мы все знаем, естественна только материнская титька. Я вот продолжаю считать, что система работы с патчами - это одно, а система хранения версий - немного другое. Наверное, Прокруст меня уже навсегда обидел - но мне кажется, скорее Оккам меня благословил.

Надстройки к уродскому гиту разные пробовал (хотя эту конкретно - нет, посмотрю, сенкс).

> Как мы все знаем, естественна только материнская титька.

Это в биологической жизни %) В профессиональной естественен только итеративный процесс.

> Я вот продолжаю считать, что система работы с патчами - это одно, а система хранения версий - немного другое.

У них достаточно много общего, так что разделение необязательно.

Не знаю, я практически никогда не испытывал нужды в сложной системе работы с патчами (да и про килт я узнал относительно недавно). patch/diff - мне их всегда хватало. Остальное живет на уровне коммита, желательно атомарного.

> Не знаю, я практически никогда не испытывал нужды в сложной системе работы с патчами

Везде, где задание можно разбить на два и более инкрементальныХ, автономно работоспособных изменения, нужна система управления патчами. И если эта система интегрирована в VCS, тем лучше - навыки работы с VCS по-прежнему актуальны, а патчи я вляются частью истории. Пусть даже еще не постоянной частью, но все возможности VCS к ним уже применимы.

> patch/diff - мне их всегда хватало

А кому-то и хватает и tar - нафига вообще VCS? :)

> Везде, где задание можно разбить на два и более инкрементальныХ, автономно работоспособных изменения, нужна система управления патчами.
Совершенно неочевидное утверждение (если мы говорим именно про PCS, не про VCS). Чем банальные атомарные коммиты (как это сделано в svn) не годятся? Чем там еще управлять? И чем в этом смысле любая DVCS принципиально лучше svn?

> А кому-то и хватает и tar - нафига вообще VCS? :)
VCS решает задачи, которые при помощи тара решаются очень неудобно. PCS решает задачи, которые практически не существуют (ок, у меня) при наличии VCS. Ну, или иными словами, VCS их решает достаточно удобно.

PCS = Patch Control System

> Чем банальные атомарные коммиты (как это сделано в svn) не годятся?

Тем, что мало кто с первого раза делает всё правильно. Таким людям нужна возможность вернуться назад и всё исправить (несколько раз, да %)).

>> А кому-то и хватает и tar - нафига вообще VCS? :)

>VCS решает задачи, которые при помощи тара решаются очень неудобно

PCS решает задачи, которые с помощью patch и diff решаются очень неудобно.

> PCS решает задачи, которые практически не существуют

Ты их просто не видишь пока. Альтернативно, ты всё делаешь правильно с первого раза :)

> Таким людям нужна возможность вернуться назад и всё исправить (несколько раз, да %)).
Я не вижу криминала в том, чтобы дефекты коммита N были исправлены в коммитах N+M1, N+M2, ...

> PCS решает задачи, которые с помощью patch и diff решаются очень неудобно.
Для меня patch/diff существуют только для того, чтобы послать патч в апстрим. И получить его из даунстрима. Других задач у них нет, а с этими они прекрасно справляются.

> Ты их просто не видишь пока. Альтернативно, ты всё делаешь правильно с первого раза :)
Возможно, не вижу - ибо точно у меня бывают коммиты с ошибками.

Кстати, как определить момент, когда можно перетаскивать код из PCS в VCS? Это ж все равно произвольно (и не гарантирует от необходимости последующего фикса). Дык почему б сразу не?...

> Я не вижу криминала в том, чтобы дефекты коммита N были исправлены в коммитах N+M1, N+M2, ...

"А он есть" (c)

> Для меня patch/diff существуют только для того, чтобы послать патч в апстрим.

В 21-м веке еще есть апстримы, куда посылают один мегапатч, а не серию патчей? :)

> точно у меня бывают коммиты с ошибками.

ВотЪ. Ты же не думаешь, что коммиты с ошибками кому-то нужны?

> "А он есть" (c)
Пруфлинк?;)

> В 21-м веке еще есть апстримы, куда посылают один мегапатч, а не серию патчей? :)
Ага. Приходит человек, приносит раскладку aa(bb). Это вполне укладывается в один патч. Или фиксят какую-то проблему в существующем коде. Я не помню, когда последний раз у меня в багзилле были баги с более чем одним патчем. Наверное, были - но очень-очень редко. Да, патчи иногда мне не нравятся. По результатам просмотра я прошу починить патч - тогда в багзилле старый патч убивается, на его место кладется исправленный. Потом я его коммичу. И нафига мне тут что-то, отличное от patch/diff + VCS?

> Ты же не думаешь, что коммиты с ошибками кому-то нужны?
Коммиты как таковые вообще никому не нужны. Нужен проект, собирающийся и работающий. Каким образом достигнуто это состояние (ну или небольшое множество состояний, если мы говорим про поддержку стабильных версий в виде бренчей) - пофиг. Коммитом больше, коммитом меньше...

Я тут подумал... Наверное, PCS может быть полезен дистромейкерам. Они не имеют возможности сплавлять все мгновенно в апстрим.

> Коммиты как таковые вообще никому не нужны. Нужен проект, собирающийся и работающий. Каким образом достигнуто это состояние (ну или небольшое множество состояний, если мы говорим про поддержку стабильных версий в виде бренчей) - пофиг. Коммитом больше, коммитом меньше...

В проекте с числом коммитов больще 3-х бывает интересно какой коммип привел к возникшей регрессии.

Мысль не распарсил - точнее, как она конфликтует с тем, что одно изменение может быть в виде "коммит + несколько фиксирующих коммитов".

> Приходит человек, приносит раскладку aa(bb). Это вполне укладывается в один патч. Или фиксят какую-то проблему в существующем коде. Я не помню, когда последний раз у меня в багзилле были баги с более чем одним патчем.

Эммм... причем тут ваша багзилла? Разговор начинался с бонусов, приносимых DVCS и управлением патчами для более-менее длительных разработок, а не о вашей специфической багзилле.

> Да, патчи иногда мне не нравятся. По результатам просмотра я прошу починить патч - тогда в багзилле старый патч убивается, на его место кладется исправленный.

И снова - причем здесь ты как ревьюер? Речь о том разработчике, который делает (и правит) патч.

> Коммиты как таковые вообще никому не нужны.

> Коммитом больше, коммитом меньше...

А... ну тогда конечно.

> Разговор начинался с бонусов, приносимых DVCS и управлением патчами для более-менее длительных разработок, а не о вашей специфической багзилле.
Дык я ж привел пример вполне себе длительной разработки xkeyboard-config. Не нравится - можем поговорить о гноме.

> Речь о том разработчике, который делает (и правит) патч.
Для него я тоже не вижу бенефитов. У него есть локальная копия проекта, он с ней работает, пока не достигнет желаемого результата. После этого единственным diff готовит материал для апстрима. Если он хочет сохранять промежуточный результат - тогда да, ему надо заводить локальный репозиторий git. В этом случае DVCS нужен, да.

Мораль: если нет "иерархии разработчиков" (апстрим-даунстрим-коммиттеры), DVCS не очень нужен

> Если он хочет сохранять промежуточный результат - тогда да, ему надо заводить локальный репозиторий git.

Это неизбежно, если задание более-менее сложное.

> Мораль: если нет "иерархии разработчиков" (апстрим-даунстрим-коммиттеры), DVCS не очень нужен

Ы. Я так и не понял, откуда такой вывод. Надеюсь, я к нему никак не причастен.

> Мысль не распарсил - точнее, как она конфликтует с тем, что одно изменение может быть в виде "коммит + несколько фиксирующих коммитов".

Приходится ли вам когда-либо откатывать изменения, вызванные конкретным коммитом? А переносить изменения их 1й ветку в другую?

> Это неизбежно, если задание более-менее сложное.
Если все разработчики "равны" - почему нельзя использовать единый репозиторий? Все, что требуется - это сохранение его "здоровым" после каждого коммита (ну, чтобы хотя бы юнит-тесты проходили). Это несложное требование.