‘Trunk,’ ‘tags’ and ‘branches’ are common conventions in Subversion, and most Subversion projects employ them in some shape or form, but there’s often some confusion surrounding these concepts. Essentially, ‘trunk,’ ‘tags’ and ‘branch’ all refer to directories in Subversion, but they’re used to distinguish how users handle these directories. Subversion doesn’t force you to organize your project into trunk, tags and branches, but arranging your data in this conventional format allows you to access the wealth of Subversion tutorials and guidelines online – and, of course, it makes it easier to reach out to the community for help if you get stuck! In this post, we provide a quick introduction to the trunk, tags and branches conventions, alongside some practical advice for getting the most out of these conventions.
Trunk
The trunk is the main line of development in a Subversion repository. It contains the main codebase and is always stable. In the early days of a project, there will be little need for branches and tags, as you will spend most of your time making changes and committing them back to the trunk of your repository.
Tags
The Subversion repository remembers every change written to it. This allows the client to read the latest version of the filesystem tree, but also to view the previous states of the filesystem. Users can tag certain revisions of the repository with more human-readable file names (e.g “release-2.0”) for easy reference. In this scenario, if you ever need to look at the source code for version 2.0 again, you can easily locate the tagged file and pull the code back out.
Branches
Branching is a line of development that exists independently of another line. Branches allow developers to work on code independently of the work going on in the trunk. Branches can be made either from:
The working copy:
- right-click on your working project and select branch/tag.
- specify where you want the information to go.
- add a log message to explain why you’re creating this branch.
The repository:
- from within the repository browser, select where you want to branch from and right-click
- select the ‘copy-to’ command
- specify the name of the new branch and the location where the branch should be created
- add an optional log message to describe why you’re creating this branch
So, when should you branch? Every project is slightly different, but there are some common reasons to create a branch:
1) Concurrent development branch: When performing concurrent development, to isolate development. This is the most common reason to create a branch.
2) Release branch: To tag a project and keep track of released code. Upon completing a release, the development team create a branch and tag it with a name that is meaningful to that release (e.g “release-2.0”) This provides an identifiable record of how the released code looks.
3) Experimental branch: To test a new technology that may not necessarily become a part of the main branch. If the experiment works out, the new code can always be merged into the trunk.
4) Custom branch: When modifying the code for a customer’s particular need.
You would not normally create a branch for small changes, and do not normally branch from the tags folder, as the tag folder specifies what a release looks like at a certain point in time, and branching from that folder can lead to confusion.
Ready to get started with Subversion? Binaries of the latest Apache Subversion releases can be downloaded from the WANdisco website now.