Теги Subversion и ветки

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

Использование пространства имен репозитория для передачи такой информации, как ветки / теги / и т. д., По сути, является моделью SVN; если вам нужна другая модель, вы, вероятно, действительно хотите что-то другое, кроме SVN.

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

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

Мы используем стратегию «ствол, тег, ветвь и поток».

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

«Тег» - это место, где происходит «копирование в», когда поток завершен, и нам нужно сохранить статус потока для целей архивирования. Это также позволяет продолжить разработку с определенной точки.

«Ветвь» - это когда должно произойти что-то совершенно отличное от основной разработки. Обычно ветки бывают очень редко.

«Потоки» - это то, что мы чаще всего используем. Поток разработки - это фокус, основанный на задачах, например поток для конкретного исправления или усилий по разработке (например, завершения запросов на изменение). Потокам разрешено сливаться друг с другом, но разные потоки ранжируются на основе стратегии svn. Например, у нас был один поток для выпуска cr, а другой поток для выпуска выпусков поддержки приложений. Поскольку поток CR должен был включать исправления поддержки приложений в дополнение к собственным изменениям, он получил более высокий рейтинг. Потоки с более высоким рейтингом имеют более низкие потоки (по мере необходимости), объединенные в них. Наконец, поток становится готовым к производству. Он маркируется, а затем «копируется в» транк, который затем используется (обычно, хотя иногда используются теги) в качестве основы для дальнейших потоков.

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