Самый простой способ сделать тег Subversion, который сильно настроен, состоит в том, чтобы использовать так называемый механизм копирования «W C -to-REPO» клиента Subversion, то есть операцию svn copy (или GUI эквивалента), чьим "источником" является ваша рабочая копия, а чьей "целью" является URL-адрес в хранилище.
Допустим, вы хотите сделать тег, который будет выглядеть точно так же, как ваш текущий trunk/, но который некоторые файлы удалены или изменены. Сначала получите локальную рабочую копию этого trunk/ в редакции HEAD (через svn checkout или svn update). Теперь изменяйте рабочую копию, пока она не будет выглядеть точно так, как вы хотите пометить sh. Обязательно используйте операции Subversion для всего, что добавляет или удаляет файлы и каталоги (svn mkdir, svn add, svn rm, ...).
Теперь не фиксируйте ваши изменения . Вместо этого используйте svn copy, чтобы скопировать вашу рабочую копию в новый URL-адрес тега.
$ svn copy . http://svn.myserver.com/repo/tags/my-new-branch -m "Make a custom tag"
Клиент Subversion будет эффективно создавать в месте расположения тега в хранилище копию того, что он находит в вашей рабочей копии.
Многие проекты (например, проекты Subversion и ViewV C) используют именно этот подход для создания тегов выпуска из ветвей выпуска. Как правило, существует некоторый файл исходного кода, который содержит строку версии программного обеспечения, и вы не хотите, чтобы в не выпущенном коде была строка версии, которая указала бы, что код, на самом деле, уже выпущен. Таким образом, в ветке релиза (скажем, branches/1.2.x/) этот файл исходного кода может выглядеть примерно так:
__version__ = "1.2.4-dev"
Как только ветвь релиза была протестирована и благословлена как готовая к выпуску, проект может просто пометить ветку и затем выполнить последующий коммит, чтобы исправить строку __version__, удалив бит «-dev».
$ svn checkout .../branches/1.2.x my-working-copy
$ cd my-working-copy
$ # test, test, and test some more
$ svn copy ^/branches/1.2.x ^/tags/1.2.4 -m "Tag the 1.2.4 release (almost)"
$ svn switch ^/tags/1.2.4 # make the working copy temporarily point to the new tag
$ vi ./lib/version.py # change the __version__ string to drop the "-dev"
$ svn commit -m "Just kidding. Now it's *really* 1.2.4."
$ svn switch ^/branches/1.2.x # make the working point back to the release branch
Но это означает, что есть окно времени в котором тег не содержит именно ту информацию, которую вы хотите.
Использование копии W C-to-REPO является способом, способом, проще и не имеет условия гонки.
$ svn checkout .../branches/1.2.x my-working-copy
$ cd my-working-copy
$ vi ./lib/version.py # change the __version__ string to drop the "-dev"
$ # test, test, and test some more
$ svn cp . ^/tags/1.2.4 -m "Tag the 1.2.4 release."
На этом этапе вы можете сделать одну из двух вещей. Вы можете отменить (все еще не принятые) локальные изменения в ветке релиза:
$ svn revert -R . # undo the local release branch mods
Или же вы можете и зафиксировать дальнейшие локальные изменения, чтобы подготовить ветку к следующему будущему выпуску. :
$ vi ./lib/version.py # change the __version__ string now to "1.2.5-dev"
$ svn commit -m "Begin a new release cycle."