Правильное использование тегов в SCM

Question

У меня и моих коллег возник спор по поводу значения и использования тегов в системах release / SCM.Мы надеемся, что сообщество StackOverflow поделится своими соображениями, которые помогут нам решить проблему.

Одна сторона утверждает, что теги являются ценным дополнением к управлению релизами.Пример их использования:мы делаем выпуск Maven, который создает новый тег (назовем его 1.0), который является моментальным снимком кода, используемым для этого выпуска.Этот тег должен быть ветвью, доступной ТОЛЬКО для ЧТЕНИЯ.Когда необходимо исправить ошибку, мы можем сделать копию Тега в новую ветку (назовем ее 1.1).Исправления ошибок идут туда.Эти исправления могут быть объединены обратно в Магистраль, чтобы основная ветвь разработки получила исправления ошибок.Наконец, выпускается версия 1.1, и автоматически создается Тег 1.1.Этот цикл продолжается.Основное преимущество этого тега заключается в том, что если вам когда-нибудь по какой-либо причине понадобится переиздать версию 1.0, вы можете просто выпустить тег 1.0 с уверенностью, что он никем не был изменен.Кроме того, сказать "Release Tag 1.0" чище, чем сказать "Выпустить версию 1 ветки 1.0, которая является оригинальной 1.0 без исправлений".

Другая сторона утверждает, что теги не дают никаких ценных преимуществ, особенно в такой системе, как Subversion с глобальными версиями, которые действуют как тег в CVS.Кроме того, Subversion выдает предупреждение только при фиксации тега;на самом деле это не останавливает его.Их метод разрабатывается в Trunk, и после выпуска вы создадите ветку с именем 1.0.Вы бы продолжили исправлять ошибки в Trunk, и если бы вам понадобилось повторно выпустить эти исправления в production, вы бы объединили их в ветку 1.0 и переиздали 1.0.В какой-то момент, возможно, после серьезных исправлений или функций в Trunk, вы бы выпустили и создали ветку 1.1.Цикл продолжается.Если вам когда-нибудь понадобится выпустить оригинальную версию 1.0, вам придется ознакомиться с веткой 1.0 версии 1.

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

Редактировать:Я немного обеспокоен тем, что "лучший" способ зависит от базовой системы SCM.Либо остановитесь на Subversion для получения ответов, либо, если возможно, придерживайтесь SCM-агностицизма.

Answer 1

С точки зрения, не зависящей от SCM, тег сильно отличается от ревизии.

Оба могут быть реализованы одним и тем же способом, оба представляют собой "временную линию", но их цель различна:

• тег представляет собой неизменяемый состояние, в котором на все файлы ссылаются уникальные идентификаторы.Это имя представляющий множество вещей но в основном стабильное состояние, ...)
• ревизия представляет собой транзакцию фиксации (не у всех SCM есть такие, особенно старые с "поэтапным подходом").Все коммиты не представляют "стабильное" состояние (как при "успешной компиляции" или "успешном выполнении").Они просто новый элемент глобальной истории.

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

Answer 2

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

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

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

Answer 3

Да, вы хотите использовать теги.

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

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

Проблема с svn заключается в том, что она стирает различие между тегами и ветвями.Любой всегда может зафиксировать тег, поэтому не гарантируется, что он будет фиксированным / неизменяемым.В других VCS, таких как PVCS, "тег" неизменяем.Вы можете принять командное соглашение, чтобы предотвратить фиксацию тегов, или даже, возможно, использовать перехватчики фиксации, чтобы предотвратить фиксацию тегов.

Answer 4

Мы используем теги (labels) при создании новых базовых линий.Мы делаем это раз в неделю, но некоторые команды делают это даже несколько раз в день.

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

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

Обычно мы размещаем теги (labels) только в главной ветви (или магистрали, или master, в зависимости от вашего стиля SCM), которая является точкой интеграции для всех остальных ветвей.

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

Answer 5

Мне нравится думать о тегах как о "просто причудливом названии для редакции".Я всегда думал о них таким образом, и IIRC в mercurial именно такие.Однако в subversion, как вы говорите, они действительно являются (дешевыми) копиями trunk/* to tags/fancy-name/

Честно говоря, я бы объединил эти две стратегии для достижения оптимальных результатов:пометьте и разветвляйте после выпуска.Ваш тег называется 1.0.0, ветвь 1.0-MAINT.Исправления отправляются в ветки, а выпуски исправлений снова становятся тегами (1.0.1 может быть тегом, предназначенным для псевдонима 1.0-MAINT в определенный момент.)

Однако не забывайте, что теги и ветви в subversion - это фактически одно и то же:дешевые копии.Единственное различие между ними заключается в семантике, которую вы / ваша команда приписываете им, так что это в значительной степени сводится к тому, чтобы заставить людей согласиться с одним конкретным методом и придерживаться его (может быть применено на сервере, например, запретить коммиты в тегах / за исключением координаторов выпуска и т.д.).

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

Answer 6

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

Я не могу сказать вам, сколько раз кто-то приходил ко мне и говорил: "Этот код микроконтроллера не работает, вы можете помочь?" и я спрашивал их: "Какую версию вы используете?" и они отвечали: "Я не уверен", потому что они плохо справляются с управлением выпусками (по крайней мере, приклеивают наклейку на устройство, лучше поместить информацию о версиях в EEPROM, которую можно запросить в режиме реального времени).>:(

Answer 7

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

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

Answer 8

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

В то же время, когда пришло время делать 1.0.0, я бы поместил его в ветку 1.0.Таким образом, поток является:разветвляйте магистраль до версии 1.0, помечайте эту новую версию 1.0 как 1.0.0 и развертывайте.Затем исправления ошибок могут быть сделаны в ветке 1.0 (чтобы избежать путаницы с любой разработкой, ориентированной на 1.1, которая, возможно, уже находится в trunk сейчас) и объединены в trunk.Каждый выпуск исправленной версии 1.0 помечен как 1.0.x из ветки 1.0.По сути, это подход, который мы используем при работе с Perforce, и он действительно очень похож на Subversion.(Читая ответы, я думаю, что это практически идентично рекомендации Винсента)

Что касается комментария о том, что теги являются избыточными, потому что у вас есть номера версий --- это в основном верно, за исключением того, что теги также определяют область видимости:т. е.какие файлы в репозитории охвачены тегом.Вы можете разумно попросить кого-нибудь посмотреть / svn/proj1 / tag / 1.0.0, и они сразу же увидят согласованное рабочее пространство.Если вы попросите их просмотреть ревизию X, они должны сначала просмотреть ревизию X, чтобы увидеть, что она изменяла (скажем) /svn/proj1/trunk/Makefile и, следовательно, сделать вывод, что / svn/proj1/trunk /@X - это то, на что им следует обратить внимание.Что произойдет, если редакция X коснется файлов в proj1 и proj2?Что, конечно, зло, но, строго говоря, вы должны говорить /svn/proj1/trunk/@X.И где хранится список номеров ревизий?Откуда мы знаем, что 1.0.0 - это редакция X?Имхо, это должно быть возможно определить только из репозитория.

В таких системах, как Git, теги и ветви - это все еще в основном одно и то же (просто ссылки на базу данных объектов), но конвенция заключается в том, что ссылки на теги не меняются, а ссылки на ветви меняются (и предпочтительно с определенным ограничением на то, как они изменяются).Perforce также имеет "метки", которые представляют собой способы группировки набора ревизий файлов независимо от списка изменений;который по сути является тегом, но более запутанным:исторически мы использовали номера списков изменений (эквивалентные номерам ревизий Subversion), дополненные названием ветки, в которой они должны находиться, для идентификации версий.Эти два почти идентичны в любом случае, так что здесь, я думаю, TMTOWTDI.