This week I will be transitioning from Microsoft Team System to Subversion for our source control system. There are two main reasons for this change - cost and ease of use.
Cost
The cost issue is two fold – first there is the internal cost of using the Team Editions of Visual Studio. For the MSDN subscription, Team Edition (not Team Suite) runs $1000 more per develper, per year than Visual Studio Professional. While this is not bad for a small team, it’s prohibitive if you are looking at growing significantly, or standardizing across large group. I can think of many useful ways to spend $7,000 per year besides sending it to Microsoft. Not that Team System is not cool and useful, but in the end, I just don’t see it being $7,000 per year cooler than Subversion + TRAC (open source issue/bug tracking system) and that’s the real bottom line – value.
The second cost aspect is somewhat inverse – if we are using Subversion and an open source build/unit testing/coverage/installer stack, then we can ship this to our clients. Since we build state level enterprise systems, and most of our clients expect to take on the longer term support and maintenance of the system, there is some serious value in being able to turn it all over to them as a comprehensive development platform. If we are on Team System, then it would be doubtful if we could ship the whole stack.
Ease of Use
Since Team System is fully integrated into Visual Studio Team Edition, the user experience for most things is pretty good. Actually I really like the check-in rules you can implement. However, we have had many issues working with web projects, as well as dealing with “other” files such as CodeSmith templates. Of course CodeSmith does not “know” about Team System, so it can’t automatically “check out” the files prior to editing them. Since Team System sets your working copy to read-only when you check in (there may be a way to change this – not sure), in order to make a change to my template, I need to open Visual Studio (slow), connect to Team Server (slow), navigate to the templates in source control, check out the file, make the change, go back to Visual Studio and check in the file again. Compared to working with Subversion, this is a major pain.
The Transition
At this point we have our Subversion server setup, and our domain accounts are authenticating through Apache. All is well. The next step is at the end of our current Sprint, get the latest code from Team System, do a build, run all the tests, clean the solutions (using Omar Shahine / Jeff Atwood’s Clean Sources) and then load the files into Subversion. I did some Googling for tools which would take the history etc. along for the ride, but I did not find anything. At this point we are early enough in the project where losing history would not be too much of a problem, and we’ll be able to have the Team Server running for at least 6 months incase we really need to get some old version.
Tools
At this point we are planning on using the very well regarded TortoiseSVN as the main client for Subversion, but we’ll also be trying AnkhSVN and VisualSVN to handle the Visual Studio integration. I’ll let you know how those tools pan out.
