Moving to Subversion
Last week, I decided to spend some time investigating Subversion as an alternative to using CVS at CodeFutures. The timing for a move seems good for two reasons - firstly, we've just released FireStorm/DAO 2.4 GA, and secondly, our CVS repository is very slow when tagging releases and is causing much frustration for the engineering team.
There are 3 reasons why I think that a move to Subversion will be beneficial:
1. Subversion supports directory renames, whereas CVS doesn't.
2. Subversion offers fast branching and tagging.
3. Subversion is being actively developed and enhanced, whereas CVS isn't.
We installed the RPM version of Subversion 1.1.3 on the same machine as our CVS server and had a new repository up and running in minutes. The documentation is extremely good, especially for an open source project.
At first glance, Subversion appears to be very similar to CVS, albeit a more polished version that is slightly easier to install and use.
However, when it comes to branching and tagging, Subversion and CVS and very different. The Subversion approach is far simpler conceptually. For a start, there is no difference between a branch and a tag. Both are simply a snapshot of a tree at a given point in time, and it is possible to then start committing changes to that copy (if you intend to commit changes then you would think of it as a branch, otherwise you would think of it as a tag, but Subversion makes no such distinction).
When you branch/tag in Subversion, a complete copy of the tree is made, but Subversion is clever enough to do this virtually on the server so the operation is immediate and uses very little extra disk space i.e. it does not actually make a full copy of the tree. This is very appealing, as we like to tag every single build of our software that goes to a customer or prospect.
The main problem I imagine for most users moving to subversion is deciding how to structure the repository to handle this approach to branches and tags. In CVS, branches and tags don't affect the repository structure - multiple branches and tags can co-exist in the same structure but in a different dimension. In Subversion, each branch and tag is a complete directory.
The documentation suggests that at the root of your repository you have 3 directories:
Trunk/
Branches/
Tags/
The idea is that development pretty much always happens on the "Trunk" copy of the code, and where required, branches can be created in the "Branches" directory and so on.
I can see how this would work in a repository which contains a single project, but we have many projects within the same repository and don't want to replicate Trunk/Branches/Tags directories under each project because it would mean that every "svn update" would result in all branches and tags being updated, so we've opted for a slightly different approach.
We've created directories called "Projects", "Branches", and "Tags" at the top level. We then use a naming convention so that we can store branches and tags for multiple projects in parallel.
Repository structure example:
|
+ Root |--+ Projects |-- common |-- firestorm |-- cfweb |--+ Branches |-- firestorm-2.3 |-- firestorm-2.4 |-- cfweb-struts-port |--+ Tags |-- common-1.0 |-- common-1.0.1 |-- firestorm-2.4-b101 |-- firestorm-2.4-b102 |-- firestorm-2.4-patch-customer-xyz |
This approach means that we can simply run an "svn update" from the root of the "Projects" directory to get up-to-date code across all projects and we can be more selective when getting updated from specific branches and tags.
I'll see how well this approach works out over the coming weeks, but I'd also be interested to hear how other people are structuring their repositories to support Subversion.
Comments
Thanks for posting this, always nice to see someone else doing the same thing I am doing at the moment.
Posted by: barfieldmv | June 21, 2005 02:40 PM
4 months on, I can safely say that this structure is working out very well for us. It has been easy to apply patches to customer releases using this model and we haven't looked back since moving from CVS. We have had some frustrations with SVN tools but now that IntelliJ IDEA 5.0 has SVN support built in we are happy. I haven't looked at Eclipse lately but I imagine that SVN support is implemented there by now.
Posted by: Andy Grove | July 18, 2005 05:52 PM
I am about to switch to using this structure as well for the same reason, except that I am now pondering calling the Root folder Projects, as you have done (the issue being that some svn tools are or may be in future wired to recognised trunk/branches/tags names as 'special' as they are so commonly used).
Although I can't say how this will work out, from experience I can say that the problem I've had with the classic approach of trunk/branches/tags per project is that is creates a break in the folder structure of the check out copy where the entire repository or a group of projects cannot be manipulated as a whole because a middle layer of folders is missing in regard to the repository. This is particulary bad when you have projects grouped in folders by brand or client and there is material, such as readmes, developer guidelines, and hyperlinks in the grouping folder that must be versioned as well.
On the other hand, if we had one repository per project, it would be hard to synchronize shared items between projects, as with a single repository approach you know that if you are retriving build 'n' of 'Project A', then build 'n' of 'Project B referenced as a subcomponent of A' is the matching version that was used. The multiple repository approach would require using the external references feature, which is not as simple to master or keep track of.
The other advantage of your layout is that you don't have to script checkouts to overcome complexity - a newbie developer can be expected to safely checkout the whole repository, especially if some form of ignore flag can be put on the branches and tags tree to prevent them being accidentally checked out (I'm yet to check if this can be done, as the SVN:Ignore feature is frustrating limited to near uselessness).
Posted by: Paul Coddington | November 25, 2005 12:58 AM