How do I convince my team to drop sourcesafe and m

Question

My development team uses source safe at a very basic level. We're moving into some more advanced and extended development cycles and I can't help but think that not using branching and merging in order to manage changes is going to be biting us very soon.

What arguments did you find most useful in order to convince your team to move to a better solution like SVN?

What programs did you use to bridge the functionality gap so that the team wouldn't miss the ide sourcesafe integration?

Or should I just accept sourcesafe and attempt to shoehorn better practices into it?

Answer 1

Surely using source safe is enough reason to want to migrate to another source control system?

I used SVN and CVS at my old job and have moved to a company that uses Source safe (we are going to migrate to SVN) and just using VSS has been enough for me to take a serious dislike to it. I went in with an open mind, despite many of my colleagues from my previous job telling me horror stories about VSS I assumed that it would have gotten better since they used it.

Not being able to edit a file because somone else is/was editing it is ridiculous. I've tried to move to more distributed versioning systems like Bazzar which is made by cannonical however it's not mature enough in terms of the tools available.

Source safe gets in the way of development where SVN helps you almost every step of the way.

Plus Using tortoise Svn made code reviews a lot easier.

Answer 2

Only to the extend as you are able to herd a bunch of cats. I've been there twice and in both cases it took some serious problems in Source Safe before people saw the light. As a manager on the other hand I simply directed the team to use SVN and our productivity increased by 300% ( this was working with a group in India and in the US. We had code exchanges that used to take a long time before svn )

Answer 3

First, document all the problems you are having that can be traced to root causes within the source control system. Keep track of them for a month or so. Add on top of that missed opportunities resulting from not using it. (if you say "opportunity costs of not using subversion" you may impress an MBA-type manager). These numbers are actually an understimate of the opportunity cost because presumably you could have been doing work that provides more than your hourly bill rate of value if you weren't messing around with VSS.

For example, do you have problems where files are locked that need to be accessed by more than one person? Have you had problems with partial (non-atomic) check-ins? Do you have problems where it is difficult for you to keep track of releases of the software and recreate the repository as it was in the past? Do you have problems getting a copy of the code onto a server that doesn't have a sourcesafe client? Do you have problems automating your build and testing process because continuous integration tools can't monitor your version control systems for updates? I am sure you can think of many others.

If you can figure out the approximate time/money costs of problems caused by sourcesafe and benefits of things that subversion provides (using a generic number like $100/hr for labor costs or just hours) and any costs of late delivery of projects, do so. If you have collected data for a month or so, you can show the benefit using subversion per month.

Then present the approximate time/cost of moving to subversion. (About 8 hours to setup and migrate code, and 2 hours per developer to connect, checkout and move projects, something like that) The risk is low, since sourcesafe is still there to rollback to.

If the cost is more than the monthly benefit, you can divide the cost by the benefit to figure out the recovery period. You should also total it up over 3 years or so to show the long term benefit. Again, emphasize that the real opportunity cost is not directly calculable because you could have been adding value during the time you were trying to manage non-branched releases in sourcesafe.

Answer 4

I don't remember any SourceSafe user ever liking the product. Do your colleagues actually like it?

I've got a similar issue with CVS at my current customer's usage. Since "it works" and they are mostly pleased with it, I cannot push them to change. But daily I sure wish they would!

Answer 5

Web page summarising problems with VSS - just point people to that URL

Answer 6

The unreliability of source safe ("please fix the repository...") was enough of a sell for us. Andecdotally (I've never measured it) SVN also always seems faster. Good concurrent checkouts / merging.

I'd always figured that to a developer it was almost too obvious. SourceSafe just seems to break and die all too often to not want to replace it...