I currently manage a group of about 20 developers for a Fortune 500 company. We used CVS from January of 2001 until May of 2004 when we converted all of our repositories over to Subversion.

The advantages we received from Subversion are immense. Before our conversion to CVS from VSS, we had two full time employees managing our production builds. Upon conversion to CVS we cut that resource count down to one. This resource handled all branching and merging activities, reporting activities, and manipulation of the CVS repository to move files while retaining history. The CVS branching and merging was just too cryptic (and took too long) for anyone to want to learn it. We had two CVS "experts" in house which included me and one of my direct reports. We were constantly called in to resolve issues. I myself spent a ton of time managing the support of the CVS repositories.

After running across Subversion by chance in May of 2003, I started piloting it at home. As I used it more, I became convinced that this was a tool that my team needed in order to increase our productivity. After using it for a while, I was able to come up with some specific areas that justified our conversion to Subversion in order to maximize our productivity and code quality:

• Atomic commits - The lack of atomicity in commits was a huge problem for us with CVS. Subversion gives us the confidence that when we commit, everything went into the repository.
• The ability to back out changes before going to production - using an activity branching model, we can allow developers to branch per activity and only merge to the main source base after code reviews have been performed. If there are problems, we have one revision we can back out that includes the full changeset for that change. While the repository level revisioning was a shift for my developers to make that didn't happen immediately, it begins to make sense when an activity had to be removed from the build. In CVS we had to go through each file looking for revisions that were effected by a change. Subversion now manages this for us.
• Decreased build time. We run CruiseControl, and the checkout times we were experiencing with CVS, along with our requirement to tag of our source base after each build caused our automated build cycle to take an inordinate amount of time. With the restriction that all production changes MUST go through the build, this made emergency situations very stressful. The cheap copy functionality of Subversion decreased the time it took to get a change into source control, through the build system, and into deployment packages by 80%, greatly increasing our response time.
• Directory Versioning - this was a big deal that caused us to actually evaluate Clearcase at one point. The CVS Attic was killing us in checkout time and build time with the velocity of change we were making to the source base. When checkout times got too slow, we would have to wipe out the attic, effectively wiping out the history of our source base. With Subversion, we can remove something from the repository and not suffer performance penalties later (and still be able to get the deleted contents back).
• Simpler (and faster) branching - we no longer have a full time FTE managing branches. We are now cycling this activity through the group. Each developer can perform this activity, because it is now part of his daily work.

As a manager, converting to Subversion was one of the best decisions I have made thus far that had a such a direct and highly visible impact on the productivity of my team.

I hope this helps you make your case for Subversion. My personal opinion is that no one should even consider CVS at this point in time. Subversion is a great product and the support you get just on the mailing lists alone (from the development team no less!) is second to none.

Ron Bieber (http://www.bieberlabs.com)