Ветки функций в CVS?

Question

Согласно политике, я обязан использовать CVS в этом конкретном проекте, поэтому, даже если мне действительно нужно переключиться на что-то другое, например Git, я не могу.

Итак, мой реальный вопрос звучит так:У нас есть соглашение, согласно которому мы создаем новую ветку в CVS каждый раз, когда выпускаем релиз (мы также помечаем тегами, но это не имеет значения).Мы называем эти ветки версий, и они позволяют нам легко проверять конкретную версию и вносить в нее исправления - это и есть наши минорные выпуски.

Но сейчас меня ждут большие, связанные с риском изменения, и если бы я работал в Git, я бы создал ветку функций в мгновение ока.Однако, работая в CVS, я попробовал создать ветки функций в другом проекте и обнаружил, что все быстро пошло наперекосяк.В итоге у меня появилось много веток, и я потерял представление о том, какие ветки синхронизированы, какие нужно объединить, а какие больше не используются.

Итак, приближаясь к вопросительному знаку, возможно ли использовать функциональные ветки в CVS?Являются ли они слишком трудными, чтобы того стоить, или я в конечном итоге буду сожалеть о том, что не воспользовался ими?Должен ли я стиснуть зубы и просто начать программировать в HEAD, но изменить процесс кодирования, чтобы внести изменения максимально ненавязчивым способом?

Answer 1

Если вы единственный, кто занимается разработкой функциональной ветки, вы можете просто использовать Git в качестве системы «песочницы для разработки», а затем, как только вы внесете изменения, объединить их в свой репозиторий CVS.

Вы по-прежнему получаете преимущества контроля версий для своего промежуточного рабочего продукта.

Answer 2

Существует отличное обсуждение стратегий ветвления под названием потоковые строки что может помочь - здесь описаны преимущества и недостатки использования ветвей функций.

Здесь также рассматриваются варианты владения строками кода и политики, которые вы, возможно, захотите реализовать.

Answer 3

Одна вещь, которую следует учитывать, - это на самом деле закрывать функциональную ветвь, когда вы закончите с ней, как только вы объедините ее обратно с основной магистралью.В этом контексте закрытие просто означает отказ от ветки, а не ее реальное удаление.

Как только работа объединена, ветка действительно не нуждается в «существовании».

Чтобы быстро определить, какие ветки являются ветвями функций, я бы предложил использовать утечку соглашения об именах «FEAT_MY_FEATURE» или «FEAT_20080926» (дата начала?).Это позволит легко игнорировать все эти ветки функций при просмотре структуры репозитория.

Answer 4

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

Документирование филиалов и назначение им конкретных обязанностей немного помогло.

Нам пришлось создать инструмент, который поможет нам постепенно объединять изменения (по одному изменению за раз, вместо объединения кончиков ветвей), потому что CVS ведет себя не очень хорошо, если две ветки расходятся.

Чаще синхронизируйтесь (хотя бы раз в неделю).

Я думаю, что лучший способ подойти к этому в ретроспективе — это убедиться, что расхождения остаются минимальными, и разделить рискованную разработку на разные этапы, например, используя Scrum.

Я также советую вам прочитать Шаблоны SCM.В этой книге содержится много полезных советов.