How to convince a company to switch their Source Control [closed]

Answer 1

Any document that proves switching will lower costs. Failing that, multi-colored graphs and charts. Maybe a power-point presentation.

Answer 2

VSS totally relies on the clients to manage the database. If a client drops connection in the middle of a write over the network at just the wrong time, your file is trashed on the server. Not just the tip, but all the history. Hope you have a good backup. I've been through it. It's bad news.

VSS usage over VPN or other remote connections is abysmal. It's using SMB to transfer the data, and you have to retrieve the file and all of its deltas just to get the tip. Nasty.

I've seen VSS start to act up at 1GB of data. Database errors, etc. MS (somewhere in a FAQ or KB) says that 2GB is really the max safe limit. There are no good management tools (the clients run the asylum), so you don't really get any warning about this.

Anything with a server process to provide some level of transactions and integrity control is a superior solution.

Answer 3

The internet is littered with well written articles on the flaws of VSS. I would collect this as a body of evidence for moving away from VSS. Find a key requirement that VSS can't support (remote working, support on other OSs, tools integration) and use it to drive your issue. You then need to find a source control system that is a good match for your organisation's requirements - are you sure Subversion is that system? Set up a demonstration of your chosen system, and use this to prove its worth.

I implemented this change at a previous employer (first to CVS, and then to SVN), and while it was successful we had to build a lot of bits around the edge and rely on a lot of (sometimes unreliable) open source projects to get all the tools we needed. With hindsight I should have considered trying to evaluate professional tools such as Perforce, Vault or even Team System. Having evaluated these, I could have made a proper value judgement on whether CVS/SVN were worth their "free" price tag.

Answer 4

being able to handle branching and forking is a start.

Try using subversion for a while in parallel to vss you will most likely find many arguments to convince your boss. If you don't, your boss is right, no reason to switch.

Answer 5

Why Subversion over VSS?

• Free software
• Easier to manage
• "check-ins" are atomic!
• Easy to Branch and Merge
• Continued development (i.e. VSS is dead end)
• Better tools for tracking changes and viewing logs
• Toolset and platform agnostic, but also integrates with many tools

I made the proposal to my manager, and it was a pretty easy sell. I've found it to be much easier to use, especially for branching (our project took 5 hours to "share and pin" in VSS, and then each operation took extra time to complete!).

Answer 6

Basic answer is that you have to make the case that switching meets the needs of the business. For example:

1. lower cost of development
2. shorter schedule (another shade of #1)
3. more apt for meeting process requirements (like software requirements traceability, or build reproducibility, etc).

Making the case on these things also requires something quantitative, not just "we will lower costs because this is the right way to do it!".

One thing to watch out for is that it's too easy for a developer to convince themselves that it would be beneficial to make the change without first going through the basic business filters. Once that happens, you end up with developers who are unhappy with their tools and are doubly frustrated because they think management won't listen. If you can't check off one of the things above, them you'll have no chance of persuading management of anything (unless management is incompetent, but that's for another question).