akamike (2007-2010)

SVN Repository Structures

Fellow Lift developer Kevin Carmody and I have been looking at improving our use of SVN, from better working copy management applications to what we write in commit messages. One of the key areas that we are looking at is the structure of our repositories, which currently vary from client to client (I know, bad practice). We want to define a simple standard structure that we can adopt, and I'm interested in hearing how everyone else manages their repositories.

A structure we quite like the idea of is one that uses a repository per client, then directly within that we have directories for each project (site) that we have worked on, as we often work on multiple codebases for each client. Within each project would be the typical trunk, branches and tags. Illustrated:

This allows us to conserve how many repositories we are using, group related projects and still use branching and tagging for each codebase. Does anyone take a similar approach? Is this a common structure?

I also welcome any alternative structure suggestions as well as any advice for better integrating SVN as part of the development process. SVN has always been used in my time at Lift but only now are we really looking to get the most out of it, as a part of a larger plan to improve our development methodologies.



I work at a large online web development and marketing/advertising agency and I use SVN for all of our development.
Interestingly I have also used the same structure across some of my projects. Not sure if it is common though.
Btw our server environment is a WebDAV setup with Dev/Staging/Live for each client and/or subdomain. We checkout repositories to our local machines, edit, and then post to the DEV server. Changes are then committed back into the trunk. Once code makes it past staging (client-review) it then goes live, and a branch is created to coincide with that “live version” of the site.

Ben Lovell

That seems kinda cumbersome...
Have you considered distributed version control, such as Git or Mercurial?
That way, there is no trunk, everyone has their own branch on their individual computers which can easily be merged in to say a central branch.

Worth checking it out: http://www.joelonsoftware.com/items/2010/03/17.html

Though, I realise that this post is a little dated now - I guess you might have updated to more modern version control systems since then.

Mike Robinson

I actually did consider moving to a distributed system, it definitely has certain advantages. The thing is I would have to get it all set up and educate the rest of the team in it's use, when really I have other more important tasks to do. SVN is working fine for us at the moment, but if we do feel the need for change then I will revisit Git/Mercurial :)

Ben Lovell

Probably best to try it with a new project, would make the set-up costs much less, especially as things have to be set up for the new project anyway. As for educating the team, using something like Mercurial and a walkthrough site like hginit.com ought to help immensely - the basics as to how to interact are quite simple and learn in a few minutes. The more advanced stuff regarding branching and merging will take a bit longer, but it's still easier than SVN, and won't be approached immediately anyway. By then, hopefully everyone will be thinking in a distributed version control system mindset, so the transition should be much easier.