Question

Got a (hopefully small) question regarding SVN and checking out repos. Basically I see conflicting tutorials and suggestions regarding what to check out and when. Some will say:

svn co http://my.repos.com/project my_project

…while others say:

svn co http://my.repos.com/project/trunk my_project

When would I want to grab the trunk directly vs the entire project? In the past I’ve never had trouble with either, but I’m not sure if there are scenarios where one is preferable to the other.

Best.

Answer 1

There are a couple of other points to note about this.

1. The tags tree (and it will usually be a tree) contains hypothetically immutable snapshots of your code at a specific point in time; this is not something you want to change, as most deployments are going to be based on tags
2. Most Subversion clients complain if you try to commit changes in the tags tree, instead of just copying into it
3. For most purposes, trunk is a special case of the directories under branches; the only significant difference is that it is expected to contain the main development path

There is usually no good reason to check out the entire project, as others have pointed out, as most of the time you are only working on the trunk and one or two branches, and the entire project can eat a significant amount of disk space. The main development “branch” is most often the only thing you need.

Here’s a real-world example. Our team does all the code changes against the trunk. When we need an alpha (pre-complete) release, we just tag the trunk. Once we hit “code complete” for a given release, we create a code freeze branch, where we do all our version changes. The beta, RC and GA releases are tagged from that branch. If we need to patch a GA release, the patch is done against the branch and merged to the trunk. That way, we don’t have to worry about newer code leaking into the tested and approved GA if we need to patch something specific. It also allows us to start working on the next version of the software as soon as the code is frozen.

Also, if there’s a “side project” that is out-of-band for the trunk, you can create a branch for that and merge it when you’re ready.

Some teams like to create a branch for every bug, and some work directly on the trunk (like mine). If your team does the bug-per-branch, I’d never check out the whole project. Among other things, I’d see a whole lot of code I wouldn’t care about.

Also, just a point about the repository management as mentioned by @humble_coder – most Subversion tools are pretty easy to use when it comes to branch/tag management. For example, TortoiseSVN has a repository browser that allows you to copy things around (creating branches and tags) pretty easily, and even the svn command-line tool can be used to do the same thing as an atomic operation (we actually have a script that creates either the alpha tags, the code freeze branch, or the post-freeze release tags).

Hope this helps!