Какие соглашения об именах вы используете для ветвей и тегов SVN?

Question

Наша компания создает соглашение об именах для веток и тегов SVN, и меня не устраивает идея использовать только дату или номер сборки в именах веток / тегов.

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

Что вы думаете / используете?

Answer 1

Я всегда добавляю теги (и обычно тоже ветки) к дате в формате ГГГГММДД, после чего следует описание назначения тега или ветви.

например, 20090326_Release_v6.5 или 20090326_Post_Production_Update

Это, конечно, в стандартной иерархии соединительных линий / тегов / ветвей.

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

Answer 2

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

Стоит вспомнить, что дает вам управление исходным кодом. Имена тегов - это не просто «v1.4», это «/CashCowProject/tags/v1.4». Именование тега "/CashCowProject/tags/CashCowProject-v1.4" немного избыточно, что бы это еще было?

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

Учитывая всю эту информацию, нетрудно составить простое представление, предоставляющее вам всю необходимую информацию из последовательных и соответствующих источников, таких как:

CashCowProject
    v1.4 - 26 March 2009     :  With Added whizzbang (more)
    v1.3 - 13 February 2009  :  Best graphics!       (more)
    v1.2 - 01 January 2009   :  Upgraded security    (more)

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

Answer 3

Для ветви функции назовите ее после того, что делается. Например, я переместил наш ORM из LINQ в SQL в NHibernate и создал ветку под названием «NHibernate». После того, как вы завершили ветвь и слили ее обратно в ствол, вы можете удалить ветку, чтобы сохранить конфликты имен в будущем. Если вам действительно нужно получить ветку, которую вы можете, вам просто нужно углубиться в историю и восстановить ее.

Если у вас есть номера историй / цитат / заданий, которые имеют отношение к филиалу, я бы добавил их к названию филиала, например. "NHibernate_429", чтобы вы могли легко ссылаться на него в вашей системе отслеживания. Тем не менее, я бы всегда сначала обращался к английскому языку, так как к этому люди более реалистично будут обращаться, когда он будет в разработке.

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

Answer 4

Все наши задачи для разработчиков входят в систему отслеживания ошибок. Эта система отслеживания ошибок имеет идентификаторы, связанные с каждой задачей.

Так что для имени ветви любой задачи мы используем:

ticketId_TicketSubject

Когда ветвь содержит несколько тикетов, мы просто объединяем их в имя ветки:

ticketId1_ticketId2_Description

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

Для тегов мы помечаем его самим номером версии.

Что касается местоположения каждого филиала. У нас есть иерархия верхнего уровня, подобная этой:

/branches

/tags

/trunk

Тогда все наши продукты / проекты попадают под каждый из них в их собственных подпапках.

/trunk/project1/

/branches/project1/TicketId_Description

Answer 5

Что мы используем (в основном в соответствии с принятым соглашением):

projectName
 |
 --trunk
 |
 --tags
 |
 --branches

Под стволом у нас основной ствол.

Под тегами мы помечаем каждую версию (как внутреннюю, так и тестовую). Там мы просто используем номер версии в качестве имени тега.

Под ветвями у нас есть одна ветвь для каждой основной версии, которую мы выпустили (в нашем случае результат одной итерации XP). Они названы как основная версия ("v5.03", "v6.04"). Кроме того, у нас есть внутренние ветки для крупных изменений или специальных версий. Там наименование имеет произвольную форму, и имя должно сообщать людям, что представляет собой ветвь. Примерами могут быть «workaround_customerA», «module_x_reorg» и т. Д.

Answer 6

Лучше:

<projectname>_<Year>_<minor>_00

как:

XYZ_14_01_00

Answer 7

Мы даем нашим веткам ".X" версию, в которой теги имеют номер.

Например, ветвью будет Foo-1.2.3.X, а тегами будут Foo-1.2.3.1, Foo-1.2.3.2 и т. Д.

У нас также есть специальный тег Foo-1.2.3.0, который создается сразу после создания ветки из ствола перед любыми изменениями. Таким образом, мы можем в любой момент развести ветки и теги в исходное состояние (так как через пару дней транк, вероятно, будет другим). Эта практика немного упростила слияния, а также значительно упрощает выяснение того, какой код изменился в ветке.