Особенность веток в CVS?

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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