Надлежащее использование Тегов в SCM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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