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

Question

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

Одна сторона утверждает, что теги являются ценным дополнением к управлению релизами. Пример их использования: мы делаем релиз Maven, который создает новый тег (называет его 1.0), который представляет собой снимок кода, используемый для этой версии. Этот тег должен быть ветвью READONLY. Когда ошибка должна быть исправлена, мы можем сделать копию тега в новую ветку (назовите ее 1.1). Исправлены ошибки. Эти исправления могут быть объединены обратно в Trunk, так что главная ветвь dev получит исправления ошибок. Наконец, выдается 1.1, и автоматически создается Tag 1.1. Этот цикл продолжается. Основное преимущество здесь в том, что если вам когда-либо понадобится переиздавать версию 1.0 по какой-либо причине, вы можете просто отпустить тег 1.0 с уверенностью, что никто никогда не был изменен. Кроме того, говоря «Release Tag 1.0» является более чистым, чем «Release version 1 ветви 1.0, которая является исходным 1.0 без исправлений».

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

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

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

Answer 1

С точки зрения агностика SCM, тег сильно отличается от пересмотра.

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

• тег представляют непреложный состояние, в котором все файлы, на который ссылается уникальный идентификатор , Это имя representing many things, но в основном стабильное состояние, ...)
• ревизия представляет транзакцию фиксации (not all SCM have those, особенно старые с «файловым подходом»). Все коммиты не представляют собой «стабильное» состояние (как в «компиляции» или «выполнить»). Это всего лишь новый элемент мировой истории.

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

Answer 2

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

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

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

Answer 3

Мне нравится думать о тегах как «просто причудливое имя для пересмотра». Я всегда думал о них так, и IIRC в mercurial они именно это. Однако в подрывной деятельности они действительно являются (дешевыми) копиями trunk/* в тегах/fancy-name/

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

В то же время, когда пришло время сделать 1.0.0, я бы положил его на ветвь 1.0. Итак, поток: ветвь ветки до 1.0, пометить этот новый 1.0 как 1.0.0 и развернуть. Затем исправления ошибок могут быть сделаны на ветке 1.0 (чтобы не путаться с какой-либо 1.1-целевой разработкой, которая уже может быть теперь на магистрали) и объединены в магистраль. Каждый выпуск фиксированного 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, теги и ветви по-прежнему в основном одно и то же (только ссылки на базу данных объектов), но соглашение заключается в том, что тег refs не изменяется, а ссылки refs do (и предпочтительно с специфическое ограничение того, как они меняются). У Perforce также есть «метки», которые являются способами группировки набора файлов изменений независимо от списка изменений; который по существу является тегом, но более запутанным: исторически мы использовали номера списков изменений (эквивалентные номерам ревизий Subversion), квалифицированные с именем филиала, на котором они должны быть включены, чтобы идентифицировать версии. Оба почти одинаковы в любом случае, поэтому я думаю, TMTOWTDI.

Answer 8

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

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

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

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

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