Функциональные ветки в CVS?

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

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

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

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

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
5
0
845
4
Перейти к ответу Данный вопрос помечен как решенный

Ответы 4

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

После того, как работа объединена, ветви действительно больше не нужно "существовать".

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

Что это за «закрытие», о котором вы говорите? Я думаю, что есть способ удалять ветки, но о закрытии веток я не слышал раньше. Поиск в Google предполагает, что это может быть основано на соглашении: x.org/wiki/CvsBranchnames

Chris Vest 26.09.2008 15:29

Под закрытием я подразумеваю "прекратить использовать их / забыть о них". Как только произойдет слияние, откажитесь от ветки.

Benoit 26.09.2008 16:05
Ответ принят как подходящий

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

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

Я принял этот ответ, потому что решил поступить именно так.

Chris Vest 06.10.2008 14:49

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

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

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

Chris Vest 26.09.2008 17:00

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

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

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

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

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

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

Чтобы уточнить: вы работали в среде, где использование функциональных веток в CVS было обычной практикой, верно?

Chris Vest 26.09.2008 18:15

Другие вопросы по теме