Curing Cancer, Preventing Global Warming, and Achieving World Peace by Migrating from VSS to SVN
Posted December 15, 2008 
Comments(15)
Comments(15) I admit that the title is slightly misleading. There will obviously never be meaningful peace between the Microtards and Macophiles.
Nevertheless, if you are currently languishing under an oppressive Visual Source Safe regime, then I hope to inspire you to rally your coworkers and end the source control tyranny once and for all.
By switching from VSS to Subversion (VisualSVN Server makes it extra easy), you will be able to …
- Rename files within Visual Studio – I can’t believe that after all these years something as simple and basic as renaming a file within the IDE (even in VS2008) still doesn’t work correctly with VSS. Even if you manage to save the history of your file by remembering to change it first with the VSS client and then change it again in the Visual Studio, you are still likely to break either the continuous integration build or screw up one of your co-workers who happens to get the latest version while you are in the middle of doing this. Even AnkhSVN, the free open source Visual Studio plugin that provides integration for SVN, can seemlessly handle this scenario. All I can say is WTF Microsoft?
Interact with the repository through Windows Explorer – I definitely recommend using TortoiseSVN when interacting with your SVN repository outside of Visual Studio. It is a Windows Explorer shell extension, so you can execute all of the source control commands by simply right clicking within a normal Windows Explorer window. Some of my co-workers were reluctant to give SVN a chance at first because they assumed that it required a substantial amount of CommandLine-Fu. While SVN does have great command line support, TortoiseSVN makes it extremely intuitive and easy to use.- Use your windows password – How is it that SVN can use integrated security but VSS cannot (WTF # 2)? Not only are you forced to deal with another set of passwords for VSS, but it won’t even enforce any type of password complexity rules. As a result, most of the developers at my old job used blank passwords for 5-10 years thus making security a joke even though it was a heavily audited environment. Even if you’re not too concerned with securing your source code, you will at least appreciate having one less password to manage.
- Cease to worry about the repository size – Microsoft recommends that VSS database sizes not exceed 3 to 5 GB (no, it hasn’t improved at all in VSS2005) This is a rather serious limitation since the two places I’ve worked at before that have used VSS both easily surpassed that mark despite having a relatively small number of developers. Besides requiring a lot less space because revisions are stored as differentials, SVN has no inherent size limitations after which corruption starts becoming likely.
- No longer have to regularly duct-tape your repository – I always found it troubling that an official Microsoft best practice was to frequently run Analzye.exe, a utility whose sole purpose is to repair corrupted files. If that wasn’t bad enough, this utility takes forever to run (4 hours where I work) and requires everyone to be out of the database while it attempts to fix the corruptions that appear to happen whenever someone hits the enter key too forcefully.
- Retrieve files faster – The solution I work in most often has 16 projects (yes I know we need to refactor it…) and doing a ‘Get Latest Version’ in VSS was painful to say the least (often taking as much as 40-60 seconds to complete). SVN updates only take that long when I am retrieving the files for the first time. After that it only transmits files from the server that have changed so it is much faster.
- Branch without fear - The last time I tried creating a branch in our VSS repository, I gave up after an hour. Subversion does the same operation in about 30 seconds and it doesn’t make the disk size swell because it just creates links to existing tree structures rather than duplicating data like VSS does.
- Work remotely without disconnecting - When VPN‘ing into work, I always had to disconnect my solutions from VSS because any interaction slowed my work down to a crawl. SVN not only consumes less bandwidth because it only sends differentials instead of whole files across the wire, but it also stores base copies locally thus allowing you to analyze changes you’ve made without even being connected.
- Maintain all of your VSS revision history – I settled on Eric Lane’s enhanced version of VSSMigrate and was able to successfully convert all of our VSS version history to SVN. Eric’s enhanced version of this utility even stripped the VSS binding information from the project and solution files during the migration, thus saving quite a bit of tedious manual work. My only complaint is that it wasn’t able to convert labels over as well, so if anyone knows of another utility that does this please let me know.
- Group and commit changes atomically – VSS doesn’t have any way to group changes together and doesn’t allow you to commit a group atomically, which means that you will be in for a world of hurt if your transmission fails halfway through a commit. SVN will not only rollback changes to the repository if any failures occur, but the revision number schema that groups changes together is also really handy for auditing and code review purposes.
More easily blame co-workers for screwups – The SVN Blame report sure does live up to its name. You aren’t sure who added that scary looking condition to a core function 3 years ago? Run the blame report and you will see a name next to each line of code so you know exactly who to go “talk” to.- Use some pretty slick tools – Since SVN is the defacto standard when it comes to source control, migrating to it will open the door to a number of very slick tools. We use JIRA and Confluence, so I’m particularly excited to try Crucible, another pretty slick tool by Altassian aimed at streamlining the code review process.
There are definitely more cutting edge options out there for source control (like Git), but if you’re coming from a VSS shop and are at all worried about encountering resistance from your coworkers or boss to a migration, then Subversion is probably your best bet. It is an extremely popular, stable, usable, and cost effective option.
Most importantly, it beats the hell out of VSS.
Now, go forth and do your part to rid the world of this horrible VSS scourge.
May God have mercy on your soul…
P.S. If you want to read a rhyming ranting by me about VSS, then check out this post
Popularity: 10% [?]
Hear hear!
I switched a little over a year ago, and the experience has been liberating to say the least.
I laughed when you said that the solution with 16 projects in it needs to be refactored. The solution I work in daily has… wait for it… *85* projects in it. The process of get latest/compile/reload web page usually takes around 10 minutes all told.
Unfortunately, we’re not moving to SVN, but TFS. I have heard that it will be an improvement over VSS, though.
[...] Read the original post: Curing Cancer, Preventing Global Warming, and Achieving World … [...]
@Brian – Yikes! That sounds like it would be a nightmare to get any work done. I can only imagine the circular reference headaches that you have to deal with every time you want to add new functionality that uses components in a new combination of ways.
I used TFS for about a year at my last job. It was definitely better than VSS, but I don’t really think it is worth the money unless you don’t already have an issue tracking system and are starting from ground zero in terms of continuous integration, test driven development, and code analysis. Even then I wouldn’t really recommend it because TFS doesn’t really excel at any of those areas and I can think of better ways to spend the money.
But, I guarantee you will appreciate TFS if you are living with VSS now.
This article is sort of priceless. I’ve been lobbying my shop for months and months to get off VSS. I finally won them over and we’re set to move to SVN this next weekend. Next up, continuous integration!
Great read and thanks.
@Brian and @Russell: We have been on TFS for a few years now and we are currently in the process of migrating to SVN. We also have found a tool that carries history into SVN so we can shut down TFS once we are done. TFS administration sucks (takes much more time to get anything done) compared to the ease of SVN maintenance.
SVN is Forrester’s number one Source Control tool (use that fact alone to lobby for it) and is completely free. Two things that are hard to say no to by any business.
Keep price and cost of ownership in mind (not just the price tag) when deciding on a source control solution. SVN beats TFS hands down in both of these categories and makes the experience of development better.
Try Bazaar :>
VSS < SVN < Bazaar
hey Robz
iam trying to migrate from vss2005 to svn but iam having trouble, so ill try to migrate to TFS and then to SVN
so Robz can you tell the name and url to download the tool to migrate from TFS to SVN
thanx
@Baseem – Migrating from VS2005 to SVN is very doable. We’re doing our final migration this weekend, but have done plenty of practice migrations where we’ve been able to move over all the history from a 5GB VSS2005 database. Try update # 4 from http://www.poweradmin.com/sour.....grate.aspx here. It strips out all the VSS bindings as well and comes with the source code so you can tweak it as necesssary (we did).
I’ll write a post on the migration process early next week.
hi russel i tried to use that tool but i get the below exception which i dont understand…:)
Unhandled Exception: System.Runtime.InteropServices.COMException (0×8004D694): An item with the name $/.Net/3rd Party/PocketPC_GraphControl_CF1.0 already exists
can u help..
thanx
@Bassem – Is the .Net/3rd Party/PocketPC_GraphControl_CF1.0 already in Subversion? Each time I reran the migration, I had to delete the existing projects from subversion before it would work. It seems to error out instead of skipping or overwriting projects if they already exist in subversion.
Russel it does not exist in svn i made a brand new repository……. i think it has something to do with the history…..any ideas
@Bassem – If it is a problem with the history, then the only option is to run VSSAnalyze and hope that fixes the problem. If it doesn’t, then you’ll have to temporarily remove the problem file from VSS before the migration and manually add it to subversion afterwards.
I ran into 2 files out of several thousand that had the historical revisions corrupted and that couldn’t be fixed by VSSAnalyze. That was a small enough percentage that it wasn’t a big deal for us to lose the revision history for those files.
the effect of Global Warming these days is even worst. i think every government should pass stricter laws on Carbon Emissions. we should also concentrate more on renewable energy sources and avoid fossil fuels.