Over the years I've constantly heard horror stories, had people say "Real Programmers Dont Use VSS", and so on. BUT, then in the workplace I've worked at two companies, one, a very well known public facing high traffic website, and another high end Financial Services "Web-Based" hosted solution catering to some very large, very well known companies, which is where I currently Reside and everything's working just fine (KNOCK KNOCK!!).

I'm constantly interfacing with EXTREMELY Old technology with some of these financial institutions.. OLD LIKE YOU WOULDN'T BELIEVE.. which leads me to the conclusion that if it works "LEAVE IT", and that maybe there's some value in old technology? at least enough value to overrule a rewrite!? right??

Is there something fundamentally flawed with the underlying technology that VSS uses? I have a feeling that if i said "someone said VSS Sucks" they would beg to differ, most likely give me this look like i dont know -ish, and I'd never gain back their respect and my credibility (well, that'll be hard to blow.. lol), BUT, give me an argument that I can take to someone whose been coding for 30 years, that builds Platforms that leverage current technology (.NET 3.5 / SQL 2008 R2 ), write's their own ORM with scaffolding and is able to provide a quality platform that supports thousands of concurrent users on a multi-tenant hosted solution, and does not agree with any benefits from having Source Control Integrated, and yet uses the Infamous Visual Source Safe.

I have extensive experience with TFS up to 2010, and honestly I think it's great when a team (beyond developers) can embrace it. I've worked side by side with someone whose a die hard SVN'r and from a purist standpoint, I see the beauty in it (I need a bit more, out of my SS, but it surely suffices). So, why are such smarties not running away from Visual Source Safe? surely if it was so bad, it would've have been realized by now, and I would not be sitting here with this simple old, Check In, Check Out, Version Resistant, Label Intensive system. But here I am...

I would love to drop an argument that would be the end all argument, but if it's a matter of opinion and personal experience, there seems to be too much leeway for keeping VSS.

UPDATE: I guess the best case is to have the VSS supporters check other people's experiences and draw from that until we (please no) experience the breaking factor ourselves. Until then, i wont be engaging in a discussion to migrate off of VSS..

UPDATE 11-2012: So i was able to convince everyone at my work place that since MS is sun downing Visual Source Safe it might be time to migrate over to TFS. I was able to convince them and have recently upgraded our team to Visual Studio 2012 and TFS 2012. The migration was fairly painless, had to run analyze.exe which found a bunch of errors (not sure they'll ever affect the project) and then manually run the VSSConverter.exe. Again, painless, except it took 16 hours to migrate 5 years worth of everything.. and now we're on TFS.. much more integrated.. much more cooler.. so all in all, VSS served it's purpose for years without hick-up. There were no horror stories and Visual Source Save as source control worked just fine. so to all the nay sayers (me included). there's nothing wrong with using VSS. i wouldnt start a new project with it, and i would definitely consider migrating to TFS. (it's really not super difficult and a new "wizard" type converter is due out any day now so migrating should be painless). But from my experience, it worked just fine and got the job done.

closed as not constructive by FrustratedWithFormsDesigner, gnat, Tom Squires, Robert Harvey, JeffO Mar 2 '12 at 17:59

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    You want to bring this debate here too ? – Nettogrof Mar 2 '12 at 16:59
  • 1
    Maybe if you re-phrase this in a less flame-bait way... – FrustratedWithFormsDesigner Mar 2 '12 at 17:00
  • You have some good ideas hidden in a ranty post. You might want to edit it to tone it down or it's likely to be closed. – Karl Bielefeldt Mar 2 '12 at 17:00
  • 1
    Here some insight from a similar question: programmers.stackexchange.com/questions/24910/… – DevSolo Mar 2 '12 at 17:17
  • @DevSolo, that was an awesome post, thank you... i will most likely check that out from time to time to perk me up, but i saw very little concrete evidence against VSS. – hanzolo Mar 2 '12 at 17:23

The fundamental problem with technologies like Access and SourceSafe is that they are shared-file solutions. This makes them vulnerable to catastrophic crashes (yes, it's happened to me before).

That said, if you're working in a very small developer environment, SourceSafe works perfectly fine. Checkouts are exclusive by default (unless you enable "multiple checkout" mode, which I've never used), which means only one person can work on a file at any given moment, but if you're all in one room, that's not an issue.

Everyone should be required to check in when they leave for the day. The person who doesn't check in and then takes a day off gets to buy everyone donuts when he gets back.


The problem isn't how "old" it is. VSS suffered from the same problem a lot of Microsoft technologies had: something originally designed for a single user had some design decisions that caused problems with multiple users, like the lack of atomic commits and dependence on shared file access.

It looks like Microsoft fixed a lot of those issues in 2005, but it's sort of the case of "too little too late." By that time most people had moved onto other systems that had other modern features they liked and none of the problems.

  • I understand.. but this reason will not hold up in an argument against VSS. – hanzolo Mar 2 '12 at 20:30

The SVN Book points out one very critical thing that i didn't quite realized the value of it but now i deeply endorse it. I don't have exact excrept but here is the jist:

VSS philosophy is that conflict is bad. So avoiding conflicts (by way of exclusion) might looks like a solution but that is really not good.

In case of SVN (and also true for others) - first off, there can be mechanism to merge things without conflicts - but even if conflicts do happen, it is a good thing! Conflicts implies that two developer were attempting to do something similar simultaneously and conflict thrown by SCM, actually forces them to talk.

Conflicts motivates communication where as exclusivity locks you out

  • 1
    Why would two developers ever work on the same class at the same time? That just makes no sense to me. – Robert Harvey Mar 2 '12 at 17:18
  • I have found this many a times in my organization. This is not extremely frequent but it does happens. There are always some modules which are not authored exclusively. – Dipan Mehta Mar 2 '12 at 17:21
  • 1
    There was good reason for exclusive check out for VB6 and other classic versions of VB. It was painfully easy to corrupt FRX binary files or hidden form definitions, ruin COM compatibility or encounter a host of other problems when multiple developers tried to work on the same project/files. – jfrankcarr Mar 2 '12 at 17:35
  • 2
    Surely the more common situation is where two people are adding a class to a project, thus both needing the project file. – pdr Mar 2 '12 at 17:42
  • 1
    @RobertHarvey: No. it is unnecessary. Conflicts are easy to resolve in most cases. – asthasr Jul 1 '13 at 13:09

Often it's a matter of priorities and costs. Changing a source control system for a large team of developers can distract from higher priority projects and, even if the software is free, cost in terms of developer time. I've been through 2 VSS to TFS and one VSS to SVN transitions and it wasn't quite as smooth as was hoped. Your manager doesn't want to tell a VP that his very important project was delayed because of some crazy team internal project.

It's kind of a "if it ain't broke, don't fix it" mentality. You see this in other areas as well such as the slow transition away from Windows XP in corporate IT departments. Basically, for the change to take place, you have to give logic reasons why the cost and limitations of keeping the old way is greater than moving to something new.

Not the answer you're looking for? Browse other questions tagged or ask your own question.