У меня сложилось тревожное впечатление, что теги на самом деле не являются чем-то особенным или ядром для Subversion, но вместо этого они представляют собой произвольную концепцию, просто папку с копией файлов определенной версии, это правда? Если это так, это не так полезно, как эквивалент, скажем, в ClearCase.
Это абсолютно правильно. И ветви тоже. Филиалы тоже просто каталог, который используется для создания филиалов.
Однако то, что это сделано таким образом, не означает, что они бесполезны. Тэги обычно используются для создания снимка вашего хранилища в определенный момент времени. Например, я хочу сделать сборку и пометить файлы, используемые в этой сборке. Позже, когда мы решим сделать релиз, я хочу пометить те же самые файлы своим номером релиза. Метод маркировки в Subversion работает так же, как и в ClearCase.
На самом деле тегирование в Subversion намного лучше, чем в ClearCase. В ClearCase мне сначала нужно создать тип метки, а затем применить этот тип метки к версии каждого файла, который я хочу пометить. Если вы помечаете, скажем, 10 000 файлов, это может занять около 20 минут. В Subversion тегирование происходит мгновенно. Пометка 10000 файлов занимает меньше секунды. Пометка 100 000 или 1 000 000 файлов занимает больше времени.
В Subversion вы можете получить список всех тегов, просто перечислив содержимое каталога tags. Это дает вам список фактических тегов. В ClearCase вы можете сделать только lstype -type lbtype, который дает вам типы меток, но это не обязательно означает, что любая из этих меток на самом деле есть в любых файлах.
В Subversion теги и ветви обычно имеют разные пространства имен. В ClearCase они используют одно и то же пространство имен, поэтому вам обычно нужно что-то сделать, чтобы отличить теги от меток. Стандарт заключается в том, что теги прописные, а метки строчные.
В Subversion вы также можете видеть, когда и кем был применен тег. В Subversion теги и ветви имеют разные пространства имен. А поскольку теги являются просто каталогами, гибкость, которую вы можете использовать для тегирования, бесконечна:
- На некоторых сайтах есть каталог
tags и специальный каталог для obsolete_tags. Если тег больше не нужен, его можно переместить в устаревший каталог. Это означает, что список тегов в каталоге тегов содержит только соответствующие теги. Однако разработчики все еще могут видеть устаревшие теги.
- Некоторые сайты используют разные каталоги для тегов сборки и выпуска тегов. Таким образом, если вы пытаетесь просмотреть список всех различных тегов выпуска, вы не смотрите на тысячи тегов сборки.
- Некоторые сайты имеют разные каталоги для разных клиентов или типов релизов. Таким образом, вы можете говорить о выпуске Acme 3.4 против версии Vegco 3.4.
Большим преимуществом меток ClearCase является то, что типы меток ClearCase могут быть заблокированы, поэтому их нельзя перемещать или применять, если владелец типа метки не разблокирует тип метки. Однако в Subversion есть много сценариев ловушек перед фиксацией, которые могут делать более или менее то же самое. У меня есть тот, который позволяет вам создать тег, но не изменять его.
Другие скрипты хуков идут дальше. Файлы и каталоги Subversion могут иметь свойства, установленные для них. Я видел хуки, которые позволяют человеку, создавшему этот тег, поместить свойство «tag-tag» в каталог, чтобы предотвратить его изменение. Removign свойство «lock-tag» позволяет изменять тег. Это позволяет тегам Subversion имитировать поведение в ClearCase.
В Subversion ветви и теги очень хорошо видны разработчикам, и их гораздо проще применять и использовать, чем их счетчики в ClearCase. Многие другие системы контроля версий эмулировали то, что Subversion делала с тегами и ветвями, потому что она делает всю систему более заметной, чем более старая система, обнаруженная в ClearCase, CVS и более старых системах контроля версий, где теги и ветви - это просто атрибуты, прикрепленные к отдельным файлам. .