This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Subversion Repository Configuration for SaaS
When you start using Subversion, you should look at some recommended directory layouts. If you just put your project at the root of the repository, then you haven’t left room for Subversion’s branches, which exist as directories alongside your main project directory.
You should, at the very least, have a /trunk directory or equivalent, as recommended in this Subversion manual. This gives you some room to grow.
Once you start adding branches, you might want to customize the layout to suit your particular process.
As a SaaS company that values each developer having their own space where they can be creative, we’ve customized our repository layout. Our layout isn’t for everyone, but perhaps it’ll give you some ideas and start your thinking process for how to get the most out of Subversion at your workplace.
Here are Codesion’s in-house rules:
1. One Project per Repository
We use a project-based architecture that allows you to add multiple repositories, separate Trac and Bugzilla instances, and multiple deployment targets and recipes to a project. We find a lot of value in keeping things simple and believe you will too.
The benefits of setting up one project per repository allows us to more easily permission management for tools like Trac and Bugzilla, makes our repositories leaner and faster, and makes it quicker to delete old projects.
The only downside is not being able to mix the history of related projects, but we find the need for this is rare if projects are well separated. For example, if you have a common library then perhaps it should be its own project. Subversion makes it easy to create working copies that are a blend of multiple repositories, so this isn’t as difficult as it might sound. I’m also looking forward to SVN 1.7 removing the final barrier here by making it even easier to ‘merge’ changes from a different repository, for those occasions when it’s really necessary.
2. A Clear Trunk Directory
Our trunk directory is named /v4trunk, but only because we maintained two versions of our system during a change in architecture (v3 to v4). The idea though is to have a clear trunk directory that defines the most official, latest version of your software.
The trunk should always work, or be very close to working. In general we work on new features or major bug fixes in branches, and merge those to trunk only after we’ve tested them.
3. No /tags
We’re a SaaS company so we only need to support the latest version. We just don’t find a lot of use for tags with our style of business.
4. Use /home/NAME for Branches
Instead of a /branches directory, we use /home/loginName/branchName. Each developer gets an area where they have control and can use whatever branch naming conventions or number of branches that works for them.
Permission-wise, all developers can do anything in their own branch home directories. We want to be flexible and not too controlling over a developer’s own work area, but maintain stricter rules for the trunk to ensure consistency.
Sometimes a branch will turn into a collaboration. That’s fine; SVN makes it easy enough and we find there are advantages to collaborative branches having a clear ‘owner’, which this naming scheme provides.
This is a snapshot of what is working for us at the moment. We’re pretty keen on our style of self-managed branches. Hopefully this helps provide you with a template for your own work, or at least a counterpoint to the standard layout.
What layout do you currently use? What would you like to start using? Share your thoughts in the comments below.