akamike

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.

1 Comment

Jack

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.

Leave a comment