Теги и ветки в Subversion - это просто каталоги. Концепция того, чем они являются, заложена не в Subversion, а в вашем мозгу.
Как уже говорили другие, теги являются снимками вашего хранилища в определенный момент времени и не должны изменяться. Если вы планируете изменить тег, это действительно должна быть ветка.
Например,
- Мне нужен тег, показывающий утвержденные изменения: сделайте его веткой вместо тега.
- Я хочу показать, какие файлы использовались для последней сборки: То же самое.
- Я хочу показать, какой код проверен: То же самое.
Но это не ветви! вы скулите претензий.
Очень хорошо, предложенная структура хранилища - это просто: предложение. Вы можете добавить еще один каталог, кроме trunk, tags и branches для этих подвижных тегов :
$repo/trunk
$repo/branches
$repo/tags
$repo/moveable_tags
Теперь вы можете поместить теги, которые вы меняете, в moveable_tags , а теги, которые люди используют для релизов, снимков и т. Д., В теги .
Я изменил предложенный макет хранилища ранее в одном месте, где я работал. Я хотел удалить устаревшие ветки и теги из хранилища, но руководство и разработчики возражали.
Я сказал, что удаляя , они не удаляли его из хранилища. Я мог бы легко вернуть их обратно, если это необходимо, но, удалив их, я устраню множество ненужных помех из этих двух каталогов. Однако разработчики не чувствовали себя в этом уверенно. Конечно, я могу их найти, но могут ли они?
Вместо этого я добавил каталоги obsolete/tags и obsolete/branches на уровень каталогов trunk, tags и branches. Вместо того, чтобы удалять устаревшие теги и ветки, я просто перемещал их. tags и branches не были загромождены, и руководители и разработчики почувствовали себя лучше, если бы знали, что должны найти эти устаревшие ветки и теги, если они когда-либо понадобятся.
Допустим, вы ничего не делаете с тегами. Вы используете теги в качестве снимков, и все, что вы ожидаете, будет изменено и обновлено, является веткой Есть еще моменты, когда тег может потребоваться изменить.
И Subversion лучше справляется с этим, чем большинство других систем контроля версий. Это потому, что теги содержат всю историю их создания и изменений. В большинстве других систем контроля версий история этого тега относится ко второму классу, если он вообще хранится. Вы можете увидеть тег. Вы можете видеть, какие файлы и версии находятся под этим тегом, но вы не можете видеть, кто создал этот тег и как он был изменен. В Subversion теги содержат всю историю.
Чтобы внести изменения в тег:
- Проверьте тег.
- Внести изменения.
- Передайте ваше изменение.
Или, что еще лучше, используйте svn cp, svn mv или svn delete против URL хранилища, а не против рабочего каталога. Например, я создал тег для выпуска 2.0. Внезапно мы поняли, что забыли одно очень важное изменение, которое происходит в этом выпуске. Вместо проверки вы делаете это:
$ svn cp -r 23933 -m"This change in this file should have been included in the tag" \
$repo/trunk/foo/src/foo.java $repo/tags/2.0/foo/src/foo.java
Когда вы посмотрите историю этого тега, вы увидите.
$svn log -v $repo/tags/2.0
------------------------------------------------------------------------
r23945 | david | 2013-04-03 11:21:55 -0400 (Wed, 3 Apr 2013) | xxx lines
Changed paths:
M /tags/2.0/foo/src/foo.java (from /trunk/foo/src/foo.java:23933)
This change in this file should have been included in the tag
------------------------------------------------------------------------
r23932 | david | 2013-04-10 11:18:40 -0400 (Wed, 10 Apr 2013) | 1 line
Changed paths:
A /tags/2.0 (from /trunk:23921)
Created release 2.0
Я вижу, что тег был создан неделю назад из ревизии 23921 на стволе. Затем я вижу, что файл foo.java был обновлен через неделю с версии 23933 в транке.