SVN: ствол, ветки и метки

Question

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

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

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

Теперь мы хотим пометить КАЖДУЮ версию ревизии.Другими словами, мы хотели бы иметь идеальную рабочую копию 1.0.0, 1.0.1, 1.0.2 ...

Теперь это мое решение, я хотел бы знать, согласны ли вы

1. Я извлекаю свою версию с тегами 1.0.0 в локальную папку / tags
2. Я разветвляю эту версию в папку /branches/1.0.1 репозитория
3. Я извлекаю свою новую ветку в папку local / branch
4. Я исправляю ошибки в ветке 1.0.1
5. Когда после x коммитов все в порядке, я отмечаю эту новую версию на/tags/1.0.1

и так далее для каждой новой ошибки / нового выпуска.Я попробовал это, и если я извлекаю папку / tags, я вижу все версии, perfectyl работает.

Теперь, когда я буду готов с 1.1.0, я должен слить последний тег (или Branch, они должныбыть одинаковым в конце, если все правильно) на магистрали, используя опции «Объединить ряд ревизий».Когда все объединено, у меня должна быть полностью рабочая версия 1.1.0 с исправлениями, исправленными в прошлом.Скомпилируйте, протестируйте, а затем опубликуйте и, очевидно, отметьте его в папке /tags/1.1.0 на сервере.

Что вы думаете?Спасибо, Марко

Answer 1

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

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

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

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

Answer 2

То, что вы описали, звучит как обычная процедура пометки и ветвления для меня. Именно так я использую Subversion, и она работает очень хорошо.

Answer 3

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

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

Answer 4

звучит хорошо для меня.

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

Наличие ветки для каждого основного выпуска и использование ее в качестве «ветки обслуживания» хорошо работает для нас.

вот описание процесса, если вы заинтересованы: Стратегии развертывания SVN для нескольких групп разработчиков (не совмещенных), работающих над различными компонентами одного и того же проекта

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