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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мне нравится думать о тегах как о «просто причудливом названии версии». Я всегда думал о них таким образом, и 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, которую можно запросить в реальном времени). > :(

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

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

Я бы совмещал оба подхода. Каждый раз, когда вы делаете релиз, помечайте его. Теги никогда не должны изменяться, поэтому наличие тега «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.