When do I check out TRUNK vs the FULL PROJECT in an SVN repo?

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.

Ergo

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!

Komsomol

Answer 2

usually a subversion repository has 3 main directories :

1. branches
2. tags
3. trunk

Trunk is for the most up to date branch of the code.

Branches are usually created in order to develop a specific feature that you do not yet want in the trunk.

Tags are like save-points of the trunk.

If you do a checkout at the root of the project, you will get all the branches, all the tags and the trunk. This can lead to a huge amount of data.

For example, if each code release is tagged, you will get the source code from all your past releases !

I hope this will help you

Jerome Wagner

Emit

Agreed. And most of the time most developers won't need anything more than /trunk and the branch or two that they're working/resolving bugs on. The rest - especially the tags - will be used rarely. I mainly go to my tags in an attempt to reproduce a bug report. It's a reliable way to know you have the same version as the user. – Charmine

Answer 3

It depends on how do you lay out your repository, but usually, you'll have this structure:

/trunk
/tags
/branches

Inside both tags and branches, you may have several copies of the project (depending again on how do you use the repository).

If your repository is laid out this way, and you checkout /, you will end up with several copies of the code (tags and branches), that you may not be supposed to be touching (tags, for instance).

If you checkout /trunk instead, you'll only check out the version you are currently working on, which is what you usually want.

Helot

Ah, so if I were the project lead then I may want to check everything out so as to handle branches, etc.? – Ergo

You may, but you also may check out only the trunk, or a single branch, and use the svn switch command to switch your working copy from one branch to the trunk. You may find that checking out the whole project will eat up a lot of disk space, more so if you use tags and branches often. – Helot

Answer 4

I would never checkout the whole project. Typically, I am only interested in one branch at a time, maybe two, occasionally three. I always have trunk checked out and updated. If I need to check the operation of a released tag (maybe for bug investigation) I check it out, investigate and delete. Branches stored under branches typically have a much shorter attention span, that is, they are created and used feverishly for a short period and then never touched again.

Selfdevotion