The Subversion team has released version 1.4 of its popular version control software. You can check out the release notes over at the official site get the the details, but here’s a summary of the changes, pulled directly from the aforementioned release notes:
- svnsync, a new repository mirroring tool
- Huge working-copy performance improvements
- Support for BerkeleyDB 4.4 and its “auto recovery” feature
- Size improvements to the binary delta algorithm
- A handful of new command switches
- Many improved APIs
- More than 40 new bugfixes
I was going to post about this yesterday, but I wanted to make sure I had the software built and installed here at the Labs before throwing the link out there. The upgrade went relatively well. Since I still use Berkeley DB for some of the repositories here, I build my own software to minimize the amount of dumping / loading I have to do. Currently I am still running Berkely DB 4.2. Referencing this during the build allowed me to avoid some problems people have reported using pre-packaged distributions that upgrade Berkeley DB for you, rendering your repository useless. Building my own also allows me to get the software without waiting for the binary distributions to become available.
One note on the upgrade. I’ve been a little lax in upgrading my Apache server (also custom built) and was running version 2.0.48 or so. The new release requires an up to date version of the apr libraries, so this also forced me to upgrade Apache to 2.0.59. Overall, the upgrade was painless.
As mentioned above, this release also includes the svnsync tool, which is a repository mirroring tool. From what I’ve read so far, the destination mirror must remain read only – there is no synchronization between two duplicate repositories (at least from the limited reading material I’ve found around so far), so this release by no means invalidates the SVK tool. Nevertheless, the working copy improvements and the mirroring capability shows that the team is still on the right track.
Also noted in the release notes:
… the new working copy format allows the client to more quickly search a working copy, detect file modifications, manage property metadata, and deal with large files. The overall disk footprint is smaller as well, with fewer inodes being used. Additionally, a number of long standing bugs related to merging and copying have been fixed.
I’m going to reserve judgement on these improvements until I get the Solaris boxes at work upgraded. The working copies are really an Achilles heel on Solaris environments, where 20 or so developers use one machine to do all development. We’ve had a number of inode-maxouts over the last year or so. When I get these machines upgraded, I’ll post a follow up on the performance on Solaris.
One other enhancement I’m glad to see, the diff and merge commands now support a -c option which you can use to merge one revision between branches. This allows you to avoid using a revision range for a simple one revision merge. This should simplify things a bit …
Subversion is still, overall, the best version control tool I’ve worked with thus far (and I’ve worked with quite a few of them). Kudos to the team on the new release. I like what I see so far …
Bieber Labs 
This is sort of a tangential question that I’ve been meaning to run by you…
Right now, all of my version control resides on CVS. I’d like to move to SVN but I need a compelling reason as it needs to buy me something that either CVS can’t do or CVS can’t do well.
First, all of my software is divided into granular components. Right now, each component sits in its own CVS module.
Second, I have production access to all of my clients. I’ve been playing with the idea of a build system that can build all of my components and deploy them to my client. Currently, we build and then manually deploy the software.
Third, each client has its own environment specific configurations, again in CVS. This will need to be taken into account for #2.
All of this is resulting in ~30+ CVS repositories and there’s a good chance that as I add more clients I’ll need to do a lot more customer specific branching and versioning. Right now we have everyone on the same branch but there’s no way I can maintain that over time.
I think that we’ve got the build portion down. I generate builds for each module based on a simple dependency description. I guess I don’t have a specific question beyond how SVN may help. I remember how well you did with the build at Grainger. Do you have any suggestions or maybe pointers for further reading? I’m a little lost with trying to pull off #2. This isn’t my area of expertise.
The primary compelling reason that I can give you is that Subversion is consistently improved, as CVS is not any longer (that I’m aware of).
There are a few more:
1. Support for changesets – purists will say Subversion doesn’t support “true” changesets. I say if it looks like a changeset and acts like a changeset, its good enough for me. Repository level revisioning is a huge time saver.
2. Fast branching – in benchmarks we took when initially evaluating Subversion, creating a branch took about 3 seconds on a repository that under CVS took about 30 minutes. That cut a huge amount of waste out of our process. Tags, since they are essentially the same as a branch, had the same time savings (which we do at the end of each automated build).
3. Try moving a file to a new location or renaming it in CVS during a refactoring exercise. You have to modify the repository directly. Subversion, while it doesn’t support true atomic renames yet, at least tracks the history of the file without having to manipulate the repository.
4. For the build part of it, CruiseControl can do what you want, however neither tool will provide the client specific configurations. As you know, we do post processing of the configuration files upon deployment, not build. This could work for you as well. Our deployment is a custom written tool that provides a meta language for defining constructs for what goes where.
Do me a favor, call me so that I can get some more details. As I said on the Subversion testimonial page over two years ago, “My personal opinion is that no one should even consider CVS at this point in time.”
Subversion is the perfect balance, for me, of the best of CVS and the removal of all of its short-comings.