Subversion tags

Friday 26 August 2005This is more than 19 years old. Be careful.

I’m a happy Subversion camper, I use it for all my personal projects. There’s one thing I don’t get about it though: tags. In CVS (or Perforce, or many other systems), I can create a tag (or a label as it is called in some systems). It’s a symbolic name for a set of revisions of files. In Subversion, it would be a symbolic name for a revision of the repository.

Subversion provides tags, but is gleeful about how they are implemented with the copy command: a tag is simply a copy of a particular revision of a tree into another part of the repository. The typical instructions for setting up Subversion say to create three directories at the top: trunk, branches, and tags. The tags directory is to hold the eventual tags you will create.

OK, so I understand this, and I understand that making a copy doesn’t really copy anything in the repository until the files are changed. And since this is a tag, the files will never be changed there, so the copy really is small in terms of space. But what happens to my working directory? If I ever go into the tags directory and use the update command, I’ll pull out a copy of every file that has ever been tagged, once for each tag!

Is this right? I know I don’t want to keep all those copies, so I can delete the working directories in my tags directory. They’re still in Subversion, and the “svn ls” command will show them to me. I can pull out the ones I want with “svn up tags/SomeTagName”. But I feel uneasy with “svn up” potentially pulling out a pile of files I don’t really want. Is there some other step I can take to keep the genie in the bottle?

Comments

[gravatar]
I only check out trunks (or specific branches or tags), not whole trees, like "svn co http://foo/Project/trunk Project"
[gravatar]
Yep, me too - allways check out only the part you really need. With tags you would checkout Project/trunk/tag Project-tag and work there. Full checkout I only do when I want to reorganize the repository structure.
[gravatar]
I guess it just seems a little unstable: if I'm working on the trunk and two (out of ten) branches, then I need to be careful to update in those three directories separately. I can't express interest in those three limbs of the repository and then just go to the root and ask for all the latest stuff that I care about.

For example, Perforce uses "clientspecs" to map parts of the depot onto the client filesystem. I get particular branches by adding them to my clientspec. Then I can visit the root of the depot, update, and get only the parts I want.
[gravatar]
Most svn users I've seen never check out the root of the "project", just the trunk or an individual tag or branch. That way you don't have the "unintended update" problem.
[gravatar]
You can use Subversion's svn:externals properties to create a workspace of those branches that you want. Subversion's externals are like symlinks in the repository that can refer to any other repository, or to another directory in the same repository.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.