Why do you (and/or your company) use Visual Source Safe instead of the "other" version control systems?

+20  A: 

It's on our MSDN DVDs and we're a small development shop. It does a decent job, is well integrated with the rest of Visual Studio and we've never had any problems with it.

J Francis
SVN is free, integrates well with Visual Studio, and I've never had any problems with it. Oh, and it doesn't just do a decent job, it does a great job.
snarky so early in the morning!
Jeremy B.
I upvoted this because we're in kind of the same boat. We are strongly considering moving away from it, but for a team as small as ours, it's provided no trouble. (Again, outside of missing transacted check-ins, which occasionally hoses a Cruise Control build.)
John Rudy
Source safe was never "free". The install did come with visual studio, however, there are licensing requirements for it. I think it was around $150 per dev.
Chris Lively
We run a nightly database analysis which does pick up and fix the odd problem.
J Francis
@John Rudy: Hope your SS database doesn't grow beyond 2GB like our small team's did!
Brandon Corfman
Even if you don't count money for the license, SourceSafe was never free, with all its hassle, frequent corrupted files, badly written database system which made any kind of "what else was checked in alongside this file" type of query cumbersome.
Lasse V. Karlsen
SVN Integration in VS (the free one) never worked at 100% (for VS 2005 I am talking). SVN is superior but Source Safe can do a good job on a small team. It came with VS6 Enterprise version and this is why people use it (in that time SVN doesn't exist). Now TFS exist it's an upgrade like CVS to SVN.
Of course, that would be my last choice today, but in the past (8 years ago) it wasn't that bad.
Even with the 'quotes' it looks like you're claiming that it's free.
SS doesn't do a good job for even a small team. It has a 2GB database archive limit after which your DB cannot be restored -- and SS will not tell you this! We made backups for months at our shop before discovering they were totally useless.
Brandon Corfman
The 2GB limit is exactly why we're looking to escape. We actually overran it already -- about 2 years ago. However, we were able to back up individual projects (none of which was bigger than a few hundred MB) and restore to new split DBs. But it IS a massive PITA ...
John Rudy
Brandon, how the hell do you get to more than 2GB of source code? We have had our project in VSS for years and the database is currently 78Mb. Are you checking in .exe's or something?
Martin Brown
i think the free statement comes from the fact that it was bundled in MSDN U in the old days. and as far as SVN goes - yes its free and better (we switched) but many of the VSS repositories were established before the first lines of SVN were ever written
and I can attest also that switching from VSS to SVN in the old days was not a trivial feat. to preserve our change sets for external customers we had to write a very complicated script to check out code from vss and inject it into SVN as a change set + the comments. oy..
@Martin Brown > Do you REALLY expect that in large companies that use VSS, it will only be used for source code?! It's used as a storage engine, saving powerpoints, images, documents, zip files,... It's easy for them to reach the 2Gb limit.
Never mind binary storage ... It's easy to hit 2GB if you're a consulting firm -- even a small one -- if you have dozens of clients, each with (potentially) multiple projects, especially when you have other resources (images, etc.) that are part of those projects. It's feasible!
John Rudy
I've edited my comment to remove 'free'.
J Francis
In our case, we stored Microsoft Access .MDB file versions inside SourceSafe, which was often valuable. This gets you to 2GB quickly as well.
Brandon Corfman
I've had several problems with it before even getting to 2GB. However I must say I gave up Vss because of lack of distributed development support. when your repository is a continent away (and the VPN is not so good) it is nearly impossible to use VSS
never had any problems with it? you must not be using it right!
+46  A: 

Because for so long, it was the offering from Microsoft. It was part of the development stack. When you're programming, in visual studio, on windows, for windows, it's easy to get into the habit of just using whichever product Microsoft is offering. I don't think anybody ever used it because it was stable, or because they thought it was a good product, or because they truly believed it was better than the competition. Most people who used it probably weren't aware of an alternative.

+9  A: 

Probably because:

A) It is made by Microsoft. Companies often lean toward solutions created by a company rather than open source solutions.

B) Companies are slow to change from existing solutions.

a) A lot of open source products are made by companies, too. Or would you say say CollabNet is not a company?
I think he meant client companies. As in, the audience for such a thing. And I believe he's absolutely right.
John Dunagan
Yes, John, that is what I mean. Obviously Collabnet is a company.The other thing is that Microsoft has name recognition. I'd bet dollars to donuts that most a lot of companies don't know CollabNet, unfortunately.
+7  A: 

Because it was free at the time, and 5 years ago CVS was just about as terrible and SVN was deemed too immature. My clients are switching off it in favor of either TFS or SVN. There is no reason for anyone to START using VSS right now. Absolutely none.

Dave Markle
definately. most dev leads are loath to switch the most valuable asset a firm has to new SCM without a track record. and you are right abougt CVS - we used to refer to working with it as hand-to-csv combat.
+4  A: 

We are using Microsoft TFS. We would probably use VSS if we were smaller (way smaller).

The main reason for us to go toward Microsoft is that we are a Microsoft-oriented shop and it's just normal to go with Microsoft.

+7  A: 

It was set up ages ago at my company and no one has the free time to migrate to a better alternative.

+1  A: 

Probably due to being ignorant of the alternatives (including TFS).

Ian Nelson
Gah! TFS is like VSS v1.1 -- it's only *marginally* better. For example, if you don't want to make changes directly though Visual Studio you're going against the grain.
Stewart Johnson
That's ludicrous. TFVC is a vastly superior beast to VSS.
Ian Nelson
Our experiences are clearly wildly different.
Stewart Johnson
+3  A: 

One company I know uses it simply because they have some many gigabytes of code, files, binaries, and other junk in their VSS that they don't even know if they could move it if they wanted to. I'm sure they probably could, but even performing backups on it is painful, so who knows.

Sam Schutte
+5  A: 

I have found that a lot of developers don't have solid knowledge of version control. Version control to them is "Oh, we need some place to put our code so we don't overwrite other changes". They open up VS or their MSDN account and see VSS sitting there and the problem is "solved".

My current company was using VSS for the longest time. It got so bad they had to rub a rabbit's foot every time they needed to check something in. Even with the issues, it was comfortable for them. They've used it for quite some time and it's Microsoft.

Because many developers understand so little about version control, they don't know about any other options. Either that, or they just don't understand the other options.

Shane Bauer
+7  A: 

Any version control is better than none.

VSS isn't great, and doesn't stand up well against modern offerings like SVN.

However, it comes with Visual Studio, integrates nicely and basically does the job.

I can see how lots of teams end up with it.

You also need to bear in mind that to most non-IT corporate executives: source control = protected IP.

From their point of view changing source control provider is risking the backup of their code, and therefore risking their product. If they've been using VSS for a while you can have a strong resistance to change on these grounds.

If you have a project that's running ok with VSS it's hard to find a compelling reason to switch to anything else.

That said, it's still the very last choice if you have any freedom in the decision.

I disagree that some is better than nothing when it gives you a false sense of security. If you *think* your code is being store but it's really being silently corrupted, then you're probably worse off than if you had nothing.
Just Some Guy
What Just Some Guy said. Which is better - no car, or a vehicle which fails catastrophically at speed at some unpredictable time?
I'd rather clean up a messed up VSS installation (which I've had to do) than deal with the fact that an important product just died with some developer's hard drive. VSS does do some really annoying things and it's far from perfect, but I haven't seen it silently corrupt anything.
I'm with Keith, I happily used Vss for years, mostly because I didn't know there was an alternative. Switched jobs and found SVN, and haven't looked back. We had some redicilously large Vss db's (running to gigabytes) and never had any trouble with them.
Binary Worrier
+6  A: 

Three major reasons, I think:

  • Incumbency. For all its faults people have been using it for years, in many cases over a decade.

  • It's the default - by Microsoft. Because of this it's much easier to get PHB types to sign off on than any 'third party' system, whether proven, OSS, free or proprietary. In a MS shop the hop will generally go Nothing->VSS because it's politically much easier than starting with a non-MS product.

  • Migration. If you have a large VSS repository, migrating it to something else is going to be a nail-biting exercise for the keepers of the purse-strings.


All of the above.

As for me, if (svn) yay : suck .

I know that until somebody with a Java background came over to our MSFT shop and introduced Subversion, I had issues everywhere I've gone about the clunky interface, the root canal-like check-in/out procedure, and lack of integration of not only VSS, but CVS.

The thing for me is, somebody at MSFT must have felt the pain, because they're really trying to improve later versions, or introduce other more integrated solutions like Team System. For all I know, CVS has improved since the days when I used it, as well. But I have no reason to ever go back for my personal projects.

That said, development shops are just going to be slow to go over. Those newer solutions cost. Subversion doesn't really evangelize in the MSFT developer community, and being hell to work in doesn't equate with broken, so most folks probably don't attempt to fix it.

John Dunagan
+16  A: 

I think it also comes down to fear of change. Honestly I think often people who "know better" (i.e.: they realise that other source control systems are superior) aren't very good selling a new system to people who are frightened of change.

An anecdote from last month to illustrate my point:

I'm consulting to an organisation, and a development team co-located with the folks I was consulting to was talking about what source control system they were going to use. "Visual Source Safe," says the team lead, so I went over there to suggest something better.

I started suggesting subversion, but marketing it as a "better, easier, cleaner" VSS, but with a shallow learning curve. I wasn't going to tell them about branching or anything, I was trying to sell them on the fact that the transition would be easy and painless. They weren't sure, since they've always used VSS, but they were just starting to come around.

At that point some other guy from another development team came over and enthusiastically started talking about using git, and how much better DVCSs were than centralised VCSs. He started using concepts and acronyms that were completely foreign to these guys, and totally spooked them. They ended up going with Visual Source Safe.

The most annoying thing for me is that now I ended up in their minds associated with the other guy as part of that "crazy open-source hacker crowd". :-/

Stewart Johnson
Word. Until I recently staged a source control coup, every time I mentioned SVN (in a microsoft shop - C# rocks!) people would start inching away as if the gestapo was listening. Now they love it.
David Lively

It's definitely about not getting out of the Microsoft comfort zone. Same reason everyone uses only the default libraries from MS and never branches out to other ways of doing software like using IoC containers and ORM (not LINQ). These concepts are embraced in the java community and others, but MS is more like the IBM of old.

I've used SourceSafe in the past and at some point when the source repository gets too large, you start to have massive problems with corruption and have to repair it frequently.

The Alt.NET community has whole heartedly embraced SVN. There are high quality plugins to Visual Studio that make it seamless to work with svn. There's even a one stop svn server install from Visualsvn that makes it as easy to setup svn on a windows box as sourcesafe.

+1  A: 

I wasn't here when that decision was made, but I believe we use VSS (6.0) because:

  1. At the time we had limited resources, some of which were spent on a MSDN license for my boss

  2. My Boss had experience with VSS 6.0

We have occasionally talked about upgrading to the next version, but it's never been a serious discussion. Our approach to source control and development would probably be considered non-optimal by many developers, but I can't do anything about it.

VSS 2005 is actually fully compatible with 6. I've been using 2005 "on the sly" against our 6.0 databases for years, and no-one's figured it out yet.
Greg D
Hehe, not bad. I might broach the subject again some time later this fall, because my boss really did want to move to 2005 at one point (time is a fleeting resource, alas). I'm starting to not like VSS 6.0, though it's more our approach that I don't care for.
+1  A: 

It doesn't cost up-front capital when you've already got MSDN subscriptions, it's integration with Visual Studio is superb, and it's "good enough" when you have a hard time convincing your senior developers to check things out when they're working on them.

When there's a guy who never checks anything out while he's working on it, then just checks out the entire project and checks in his entire working folder all at once, overwriting any other changes that may have taken place since he got his last drop... Do you want to explain branching to him? I sure don't. I'd be thrilled if I could just convince him to use the integration with Visual Studio.

Greg D
+1  A: 

We started using it 10 years ago because it had great integration with Visual Studio 6. We have a lot of users who are frankly way better aerospace engineers than they are software engineers, so seamless integration with our development environment is essential.

10 years later we are still using Visual Studio 'nuff said. :-(

Ouch on having to use VS6.
+4  A: 

I can tell you why we used to use it. Pre 2001 when we switched to SVN, it was the best thing going.

  • It came with MSDN U which we were buying anyway.

  • MKS, star team etc were expensive - think $400+/seat extra - not budget friendly to small shops. often required extra "server" software that was expensive too.

  • File locking was actually a huge feature- many teams used to lose work becuase updating the "repository" meant copying your source file (.c, .ccp, .h etc) to a common place. if someone else tweaked a file and didnt tell any one you lost the work. weird bugs etc. very common in small shops in the old days. stone ages. that no one could lose work by overwriting code was a big plus. I used to sit on locked files for weeks to prevent damaging changes.

  • The VSS graphical shell was easy and simple to use
  • Worked off a simple network share - no server software, no fuss, no muss
  • Unix scm was typically not available on windows and often not multi-user - rcs
  • Backup was easy - xcopy the vssdir and off you went - more or less - you'd backup the locks doing that but so what...

What made us switch?

  • Extreme Programming & continous integration
  • Realizing that change collisions on files were really rare in fact and that svn guarded against checking in delta against the non latest rev forcing you to merge.
  • The VSS repository once it gets above about 1.5gb in deltas becomes fragile
  • Tortise SVN
  • Friendly command line interface - i used to post messages on sourceforge about hand-to-CVS combat
  • Didn't get an update rev in about 10 years - we figured it was a dead/abandoned code
+2  A: 

I have to deal with a lot of unexperienced developers who have never ever used version control, let alone code applications from a single code repository (their solution was excel-based and one person in the team is responsible for the core spreadsheet and the others make changes to this "master spreadsheet" and save it in a hierarchy of folders in a central server).

When I explained the concept of code repository without file locking everybody just freaked out. When I said that we would benefit from using Visual SVN I was questioned about having to pay for a tool (when Vss is already integrated to Visual Studio, SQL Server and so on).

Unfortunately I ran out of arguments to convince people to use subversion or any other version control and, instead, I might be moving from subversion to VSS very soon (gosh how I hate this).

You could try the free Ankhsvn, to help you get over the having to pay for tools argument.


We've been using it for so long, that management refuses to entertain using anything else. We are planning on moving to TFS in the future. Its been frustrating to do branching/shelving, etc with VSS. I tried to get a move to SVN, but, as I mentioned, was shot down.

So for now, its VSS.

Bryce Fischer
+5  A: 

How it started

Because they have started using it many years ago, when alternatives were not many, those which were free (CVS) were extremely inconvenient to be used, and those which were convenient were very expensive.

VSS works

Now they have large repositories which more or less do work (yes, sometimes some minor corruption happens, but nothing which would present real risk of stopping the everyday company work), and they are obeying the rule "Do not mend what is not broken".

Fear of migration

Sometimes they even see benefits of migration to other system, but when they try, they see the conversion is a lot more difficult and slower then they had hoped, and that some parts of the repositories are not converted at all.

+2  A: 

Actually, most people use VSS because either they themselves, their bosses, management, or their companies' CEOs committed a great, heinous crime in some past life - so they're cleansing their bad karma via auto-flagellation in the worst possible way.

Joe Pineda
I believe in karma - however I must say I think I've already paid my share
I love this answer! :)
Dmitri Nesteruk
+1  A: 

I believe it is a combination of the following:

1) It has trained me well. In going to another version control software like Subversion, there is the curve of how to use it, what are good practices to do with it, and how does this impact our builds and deployment.

2) Most of the companies I've worked at use Microsoft technologies. Since VSS comes from Microsoft, it is viewed as having their blessing to use. You could think of it this way: Since I'm on a Microsoft O/S(Windows), developing onto Microsoft Technologies(ASP.Net with IIS), and using other Microsoft tools(Visual Studio), why doesn't it make sense to just toss in another Microsoft tool? This would be like ordering a ton of food from a take-out place and then stopping at 7-eleven just before to buy some drinks. Some do that for various reasons, e.g. the pop is cheaper there or your friend works there, and some see the simplicity of just doing it all at one place.

I'll admit I may have drunk more than a little of the Microsoft Kool-aid.

In a way this reminds me of the Mac vs. PC where there is the notiong that "Macs are easy to use" but this omits how much of a PC trains some of us in terms of where we go to find things like an Event Viewer or hosts file.

JB King

*Difficult to justify massive change to the business, disruption caused to projects *We're a Microsoft shop and TFS is expensive *It comes with MSDN *Subversion is OpenSource and we can't get support for it.

+1  A: 

I think a key reason is that it is a checkbox on the install for many if not all MS development tools. As such it is sort of a default solution that doesn't get replaced until you start having problems or get frustrated with it.