Subversion: эквивалент принудительного тега в cvs

Question

Процесс сборки в моей компании работает следующим образом с использованием CVS:

1. Создать ветку релиза, например B_Release_1_0
2. Пометить эту ветку тегом выпуска R_Release_1_0
3. Любое небольшое исправление к релизу будет зафиксировано в ветке релиза, и мы добавим тег R_Release_1_0. Если бы в ветке было сделано большее исправление, мы бы увеличили тег.

В Subversion я не вижу эквивалентного способа сделать это без необходимости вручную копировать измененные файлы из папки филиала в папку тегов, как описано здесь: http://svn.haxx.se/users/archive-2005-05/0345.shtml

Однако это может занять много времени и привести к ошибкам, если будет изменено несколько файлов.

Есть ли лучший способ использовать теги в Subversion или нам просто нужно полностью изменить наш подход?

Спасибо

Answer 1

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

Однако я бы порекомендовал несколько вещей ...

• Упростите названия веток и тегов. В CVS ветви и теги совместно используют одно и то же пространство имен. В Subversion они этого не делают. Вам не нужны префиксы R и B.

• Избавиться от подчеркивания. Вы можете использовать точки в Subversion. Например, ваш выпуск теперь может быть Release-1.0 вместо Release_1_0. Черт, я бы даже не стал возиться с частью Release. Просто назовите тег 1.0 и ветку 1.0.

Теперь самое главное: не используйте теги повторно! Нет нет нет. Это то, что в сообществе CM называется anti-pattern . анти-паттерн - плохая практика CM.

Перемещение тега в Subversion не так плохо, как в CVS, поскольку Subversion, в отличие от CVS, хранит историю ваших тегов и изменений. Тем не менее, тег должен быть снимком в определенный момент времени. То есть, когда я говорю о Выпуске 1.0, мне не нужно говорить «Вы имеете в виду Выпуск 1.0, который мы сделали на прошлой неделе или на предыдущей неделе» .

Я понимаю, что вы делаете, но есть лучшие способы. Прежде всего, тегирование в Subversion очень и очень быстрое. Вы делаете svn cp... и все готово. В CVS это может занять от 40 до 50 минут (что, вероятно, является причиной того, что вы начали бизнес по повторному использованию тегов).

Я рекомендую вам просто добавить что-нибудь в конец тега. Например, вы можете поместить что-то вроде: 1.0-2012-Feb-29, так что вы знаете, что говорите о Выпуске 1.0, который состоялся 29 февраля 2012 года. Вы все еще знаете, что это Выпуск 1.0, потому что он все еще начинается с 1.0, но Вы знаете , о котором Release 1.0 вы говорите.

Большой вопрос: почему вы маркируете эти релизы? В Subversion многие люди просто используют идентификатор редакции Subversion в качестве быстрого тега. Вы можете говорить о Revision 20321 вашего программного обеспечения. Тогда вы помечаете теги только тогда, когда действительно делаете настоящий релиз.

Мы используем Jenkins в качестве нашей системы сборки, поэтому для каждой фиксации существует отдельная сборка. QA берет наши сборки прямо из Jenkins для тестирования. Наши разработчики просто говорят, возьмите Build # 29 из Release 1.0 (Release 1.0 - просто ссылка на ветку). Позже QA скажет, что они сертифицировали конкретную сборку для выпуска, и мы вернемся к Jenkins и отметим эту сборку как Release-1.0 или любую другую.

На моем последнем месте мы отметили каждую сборку как Release-1.0-B-xxx, где "xxx" - номер сборки Jenkins. Мы поместили эти теги сборки в /project/tags/BUILDS/ в нашем репозитории Subversion, чтобы они не отображались, когда вы захотите сделать svn ls /project/tags, чтобы увидеть, что это за релизы. Затем, когда у нас действительно был релиз, мы скопировали тег сборки в фактический тег релиза:

$ svn cp http://build/src/foo/tags/BUILDS/1.0-B-233 http://build/src/foo/tags/1.0

Надеюсь, это поможет. Subversion заботится о многих проблемах, которые у вас были с CVS. Пометка выполняется мгновенно, каждое изменение в репозитории имеет номер ревизии по всему репозиторию, и вы можете просто использовать его в качестве тега сборки. Кроме того, даже когда вы перемещаете тег, Subversion отслеживает изменение, когда оно было сделано и кто его сделал. Вы могли бы даже спросить разницу между новым и старым тегом.

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

Answer 2

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

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

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

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

Третий вариант - просто перевести ветку релиза в новую ветку релиза и внести там исправления.Обратите внимание, что в SVN есть атомарные номера ревизий, так что вы можете применить исправления непосредственно к ветке релиза и просто записать 2 набора номеров ревизий - R_Release_1_0 v 1 - это оригинал, R_Release_1_0 v2 - это фиксированный, но, как я уже говорил в началеЭто не лучший способ сделать это (TBH, это то, что мы делаем, это работает для нас, поэтому я не буду критиковать это, вам просто нужно точно понять, что и почему вы делаете).