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.

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.