Why do companies use Source Safe?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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". :-/

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

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 6...so 'nuff said. :-(

Answer 18

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

Answer 19

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).

Answer 20

Inertia.

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.

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

*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.

Answer 25

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.