rss feed Twitter Page Facebook Page Github Page Stack Over Flow Page

Organize your SVN repository

The Trunk and The Branches, every developer with Subversion experience knows what it means. For those who are not familiar with it, each Subversion repositories should contain four (4) directories. All directories have their own purpose, and they need to be use wisely.


The trunk contains the most current code. It is basically the code that is running in production. There's only one trunk in your repository, take care of it.

Unfortunately, people use this to fix bugs or create new features. They check out, update the code and push to production. This practice should be banned since that can generate more issues than you can imagine. The trunk is only used to create branches, tags and releases.

Trunk Structure


Branches are a copy of the trunk. These branches are created independently and can be used to add, modify or delete features to the current code and to fix bugs. With that said, there is two (2) types of branches you need to consider:

Feature Branches

The Feature branch is mainly used to add, modify or delete feature to your current code. Naming your branch is a very important step. If you have a ticketing system that is used to create request to developers, I recommend using the ticket id.

For example: A business analyst request a new feature and the ticket number of this ticket is 102, then the branch name will be: 102.

This will simply your life when it's time to go back to the original request to make sure you didn't forget anything.

If you don't have such a system, you will have to generate a good name, so it is easy for everybody to remember.

For example: John Doe, (a business analyst) request a new feature, he sends is request by email to the project manager and the project manager sends an email to you. In this case, you can name the branch using the initial of the business analyst with the date/time when the email was sent to the project manager: jd-20110919-110000.

Feature Branches Structure
Bug Fix Branches

The "Bug Fix" branch is mainly to fix bugs found by QA or you in the current code (trunk). This kind of branches are created for this purpose.

The naming convention for these branches should follow the same logic as the "Feature Branches". The only exception is the fix- added as prefix. This way, it is easy to find and track back what was fix and for which purpose.

Bug Fix Branches Structure


Tags are like branches that are not used for development. In other words, they are "snapshot" with a name of a specific revision of the trunk, or of a branch.

The naming convention for these tags should follow the same logic as the branches.

Tags Structure


Releases are combined branches ready to be tested and pushed to production. Pushing one branch at a time can be painful to test, push and merge. If you have 4 branches that needs to be tested and pushed, this is what you need to create. Because it combined multiple branches, you don't need to repeat the same process over and over.

The naming convention for these releases should follow a date/time standard. For example, a release that was created on Monday, Sept 19th 2011 11:00:00 should have the name: 20110919-110000. This way, it is easy to go back and know at what day this release was pushed to production.

Releases Structure

When committing releases, the name of all branches should be included.