В соответствии с политикой я обязан использовать CVS в этом конкретном проекте, поэтому, хотя я бы действительно переключился на что-то другое, например Git, я не могу.
Итак, мой настоящий вопрос звучит так: у нас есть соглашение, согласно которому мы создаем новую ветку в CVS каждый раз, когда делаем релиз (мы также помечаем теги, но это не главное). Мы называем эти ветки версий, и они позволяют нам легко проверять конкретную версию и вносить в нее исправления - это наши второстепенные выпуски.
Но теперь у меня есть несколько крупных, рискованных изменений, и если бы я работал в Git, я бы в мгновение ока создал ветку функций. Однако, работая в CVS, я попытался создать ветки функций в другом проекте и обнаружил, что все быстро обернулось беспорядком. У меня было много ветвей, и я потерял информацию о том, какие ветки были синхронизированы, какие требовали слияния, а какие больше не использовались.
Итак, подойдя ближе к вопросительному знаку, возможно ли использовать функциональные ветки в CVS? Слишком много хлопот, чтобы того стоить, или я в конце концов пожалею о том, что не использовал их? Должен ли я укусить пулю и просто начать кодировать в HEAD, но изменить процесс кодирования, чтобы внести изменения самым ненавязчивым способом?
Одна вещь, которую следует учитывать, - это фактически Закрыть ветки функций, когда вы закончите с ней, после того, как вы снова объедините ее с основным стволом. В этом контексте закрытие означает просто отказ от ветки, а не настоящее удаление.
После того, как работа объединена, ветви действительно больше не нужно "существовать".
Чтобы быстро определить, какие ветви являются функциональными ветвями, я бы посоветовал иметь утечку соглашения об именах «FEAT_MY_FEATURE» или «FEAT_20080926» (дата начала?). Это упростило бы игнорирование всех этих функциональных веток при просмотре структуры репозитория.
Под закрытием я подразумеваю "прекратить использовать их / забыть о них". Как только произойдет слияние, откажитесь от ветки.
Если вы единственный, кто разрабатывает функциональную ветку, вы можете просто использовать Git в качестве «системы разработки песочницы», а затем, когда вы внесете изменения, объедините их в свой репозиторий CVS.
Вы по-прежнему получаете преимущество контроля версий для вашего промежуточного рабочего продукта.
Я принял этот ответ, потому что решил поступить именно так.
Есть отличное обсуждение стратегии ветвления под названием поточные линии, которое может помочь - оно описывает преимущества и недостатки использования ветвей функций.
Он также охватывает варианты владения строкой кода и политики, которые вы можете реализовать.
Есть что почитать. И документ старый. Но да, я внимательно посмотрю на это.
В течение нескольких лет я работал в среде, где это было обычной практикой и было очень болезненно. Убедитесь, что слияния являются частью вашего плана проекта, потому что они отнимают много времени и являются источниками задержек.
Немного помогло документирование ветвей и назначение им конкретных обязанностей.
Нам пришлось создать инструмент, который помог бы нам постепенно объединять изменения (одно изменение за раз, а не объединять кончики ветвей), потому что CVS плохо себя ведет, если две ветки расходятся.
Часто синхронизируйте (хотя бы раз в неделю).
Я думаю, что лучший способ подойти к этому ретроспективно - это убедиться, что расхождение остается минимальным и разбивать рискованную разработку на разные этапы, например, с помощью Scrum.
Я также рекомендую вам прочитать Шаблоны SCM. В этой книге есть много хороших советов.
Чтобы уточнить: вы работали в среде, где использование функциональных веток в CVS было обычной практикой, верно?
Что это за «закрытие», о котором вы говорите? Я думаю, что есть способ удалять ветки, но о закрытии веток я не слышал раньше. Поиск в Google предполагает, что это может быть основано на соглашении: x.org/wiki/CvsBranchnames