However, people often want to give more human-friendly names
to tags, like release-1.0. And they want to
make snapshots of smaller subdirectories of the filesystem.
After all, it's not so easy to remember that release-1.0 of a
piece of software is a particular subdirectory of revision
4822.
Once again,
svn copy
comes to the
rescue. If you want to create a snapshot of
/calc/trunk exactly as it looks in the
HEAD revision, then make a copy of it:
$ svn copy https://svn.example.com/repos/calc/trunk \
https://svn.example.com/repos/calc/tags/release-1.0 \
-m "Tagging the 1.0 release of the 'calc' project."
Committed revision 351.
This example assumes that a
/calc/tags directory already exists. (If it
doesn't, see
svn mkdir).
After the copy completes, the new
release-1.0 directory is forever a
snapshot of how the project looked in the
HEAD revision at the time you made the
copy. Of course you might want to be more precise about
exactly which revision you copy, in case somebody else may
have committed changes to the project when you weren't
looking. So if you know that revision 350 of
/calc/trunk is exactly the snapshot you
want, you can specify it by passing -r 350 to
the
svn copy
command.
But wait a moment: isn't this tag-creation procedure the
same procedure we used to create a branch? Yes, in fact, it
is. In Subversion, there's no difference between a tag and a
branch. Both are just ordinary directories that are created
by copying. Just as with branches, the only reason a copied
directory is a “tag” is because
humans
have decided to treat it that way:
as long as nobody ever commits to the directory, it forever
remains a snapshot. If people start committing to it, it
becomes a branch.
If you are administering a repository, there are two
approaches you can take to managing tags. The first approach
is “hands off”: as a matter of project policy,
decide where your tags will live, and make sure all users know
how to treat the directories they copy in there. (That is,
make sure they know not to commit to them.) The second
approach is more paranoid: you can use one of the
access-control scripts provided with Subversion to prevent
anyone from doing anything but creating new copies in the
tags-area (See
Chapter 6, Server Configuration
.) The paranoid
approach, however, isn't usually necessary. If a user
accidentally commits a change to a tag-directory, you can
simply undo the change as discussed in the previous section.
This is version control, after all.
