The Old Joel on Software Forum: Part 4 (of 5) - What is wrong with SourceSafe

What is wrong with SourceSafe

I've been reading a lot of negative stuff about source safe as a version control system and about all the benefits of alternative products, both on this forum and on "Ask Joel".

Can anyone explain me what the biggest problems are with source safe. Personally, i'm perfectly happy with sourcesafe. I find the IDE integration with VS.NET excellent, it almost eliminates the need for the sourcesafe client app.

Maybe it's just ignorance on my part and i just don't know what i'm missing, but that's a "may be"

Geert-Jan Thomas
Wednesday, March 10, 2004

I find sourcesafe works pretty well too. I think it has a reputation as not handling very large projects, hence MS dont use it internally because most of their projects are very large.

Craig
Wednesday, March 10, 2004

1. Stores everything in binary files with weird names. (aaaa etc). So in case you loose password its impossible to recover the data.
2. It has a tendency of corrupting the source database overtime. It is recommended that users run verification tool that comes with VSS AT LEAST ONCE EVERY WEEK.
3. Its not client server. So its difficult to access from multiple locations. You have to use tools like SourceOffsite. (Additional cost).
4. Since its not client server, setuping up any checks before commit/checkins etc is not easily possible.
5. Commandline version of VSS is not easy to setup. Hence including it in automatic build tools, etc is difficult.
6. Its not very good in branching/merging. Good branch and merge is vital for large projects.

Its good tool for small single site teams. Also good at storing versions of binary files.

Nitin

Nitin Bhide
Wednesday, March 10, 2004

If it runs out of space it just trashes all your files. For fun, like.

Mr Jack
Wednesday, March 10, 2004

Source Safe implements multiple versions as directories, which has a configuration cost. We found that the cost was high enough that we didn't create private or team branches, and just kept branches for releases.

Steve S
Wednesday, March 10, 2004

In additions, last time I looked at it:

1. Not client server, so everyone has to have full access to the files (go start tinkering outside of VSS and you can mess things up)

2. No directory versioning. How do people live without this?

Gwyn
Wednesday, March 10, 2004

I've had VSS corrupt binary documents. Thank goodness for backups.

We now use CVS, and are seriously looking at SubVersion for it's atomic commits and directory versioning.

Happy to be working
Wednesday, March 10, 2004

1. It doesn't track batch checkins. That is, when you check-in fifty files all at once they should be tracked as an atomic group, and rollbackable as a group. SS just handles them as fifty separate check-ins. It is possible for someone to grab a project while someone else is checking in those 50 files, and get some of those files but not others. The result is that you need to keep getting the project from SourceSafe until the waters runs clear, so to speak.

2. There's no provision for removing files from a project and having them deleted locally when someone grabs a new version of the project.

Junkster
Wednesday, March 10, 2004

Even the visual studio integration isn't that good. As soon as you branch, all of your projects are screwed up. When we used VSS, there was always someone managing to screw up the information kept in the project files, and making everything point to the wrong branch. Then if that branch gets merged and doesn't exist anymore, the VSS integration complains and complains, and you can barely get your project open at all.

I never found exclusive check outs to be very convenient, though it is just an option.

Incidentally, even though we had a fairly large code base and we almost never repaired the repository, we didn't have corruption problems.

VSS could be really slow on some actions, I think even get latest version on a lot of code took too long.

There are enough frustrations like these too make VSS truly annoying to those of us who have been hit by it. In truth, most of the issues aren't huge, and should be fixable. Microsoft has decided they aren't interested in making VSS any better!

Keith Wright
Wednesday, March 10, 2004

1. Branch and merge is more or less broken for an entire tree. It doesn't support any reasonable branching model.

2. Get your database size above 1GB and try not to have corruption. Just try :-)

3. It doesn't play well with Unicode. I understand this is being fixed in Whidbey.

Basically we used SourceSafe for up to 10 developers over 3 years, but are moving off of it now. It's outlived it's usefulness.

Rick Watson
Wednesday, March 10, 2004

On top of all the others, a big pet peeve of mine is the granularity of security.

If you give someone read/write permissions to a VSS database, they have control to all projects, all files, everything within the database. We like to segregate responsibilities around here and it's quite difficult when everybody's got permissions to everything.

I'd like to be able to grant permissions on project/folder/individual file level. VSS doesn't do this as far as I'm aware (somebody please tell me if I'm wrong.)

Sgt. Sausage
Wednesday, March 10, 2004

I used the VS97 version of VSS for 3+ years and couldn't tell you how many times I had to figure out who had the latest version of what file on their machine so I could build a new repository after VSS trashed our existing repository.

For the next three years, I used CVS running as a server on a unix box and WinCVS on my NT client and never once had a failure of the repository. Next I'll probably be trying SubVersion.

Now, despite my borne-of-experience fear of using VSS, I'd still rather use VSS than no source control at all! While it may have trashed the repository from time to time, it also saved me a number of times when I had to go back and pick up an older version of a file!

jburka
Wednesday, March 10, 2004

> (somebody please tell me if I'm wrong.)

I think you can control rights at the project/folder level (although not at the file level): start SSADMIN.EXE and see the "Tools\Rights by Project..." and "Tools\Rights Assignment for User..." menu items.

Christopher Wells
Wednesday, March 10, 2004

It's basically fine for very small, Windows-only deployments,
but if you have anything bigger, it tends to fall apart. Also,
when I used it a few years ago we did lose an afternoon
by having to restore a backup after it pooped on our
db. Since then, I haven't worked in a Windows-only
environment so it's been off radar. Perforce and other
client-server systems are more appropriate for us.

x
Wednesday, March 10, 2004

What Microsft uses internally if VSS cannot handle large projects ?

Tarek
Wednesday, March 10, 2004

Perforce (or, actually, a source-licensed version thereof)

Flamebait Sr.
Wednesday, March 10, 2004

Don't know what the latest version is like, but the one that shipped with Visual Basic 5 had an 'interesting' behavior.

I had a script that ran (as me) every day on my desktop PC to get the latest version of certain directories. This script worked fine.

One day I was working on someone else's PC, but logged in as me. I tried to get some directories, but the files I was getting kept appearing in the wrong directories.

To cut a long story short, it turned out that the working directory for the SS command being run by a user is stored in a file that is user-specific. If you try to run another SS command at the same time, it gets really confused.

So the script running on my PC was interfering with my 'get' on the other PC.

After that, I created a special user for the script to run as.

Pat Galea
Wednesday, March 10, 2004

Like any large company, Microsoft uses a variety of things. It wouldn't surprise me to know that there are SourceSafe repositories in use for small projects.

Definitely, though, they do have a modified version of Perforce that seems pretty prevalent for large projects (like, I think that's what they use for Windows).

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, March 10, 2004

If SourceSafe is a sore, then SourceOffSite is the bloody pus.

Is that what you're looking for?

Dan Brown
Wednesday, March 10, 2004

In SourceOffsite, they have a "get latest version" command.

What they should've added was a "NO REALLY, GET THE LATEST F*ING VERSION".

Sorry.

Dan Brown
Wednesday, March 10, 2004

Oh. And how in the hell is my version "old" if I HAVE IT CHECKED OUT??? Jeez. I've got the latest feaking version!

Dan Brown
Wednesday, March 10, 2004

When I was contracting at Microsoft a few years ago, we used VSS, others used CVS. I don't remember anyone using Perforce at the time, but I didn't really pay much attention.

In general, any team used whatever it felt was necessary to get the job done. I still remember the reaction when the FrontPage team tried to get people to start using their product ... something about tar and feathers ...

Mongo
Wednesday, March 10, 2004

http://www.michaelbolton.net/testing/VSSDefects.html

ICBW
Thursday, March 11, 2004

Do they still use Apache server because IIS
is still not secure and reliable enough then ? ;-)

Tarek
Thursday, March 11, 2004

Dan, you seem to be having some anger management problems <g>

Thursday, March 11, 2004

For those of you who have moved from VSS to annother source control system, were you able to migrate your code from one to the other? At my workplace, our VSS projects are huge and it's getting out of hand. We'd like to move to something else, but ideally migrate the code so that we keep all our histories etc etc.

marcus
Thursday, March 11, 2004

Vault has a VSS migration tool. They do this primarily because they bill themselves as the intelligent replacement to VSS.

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, March 11, 2004

Perforce also has a migration tool. There also one for CVS.

The big problem with SourceSafe is that CVS and Subversion are both free and Perforce has a single-user version that you can use.

So it's a really bad idea to use SourceSafe now and upgrade to something better later. You can spare yourself the trouble down the road and use a real tool now and not pay any more than you would otherwise.

Flamebait Sr.
Thursday, March 11, 2004

> For those of you who have moved from VSS to annother source control system, were you able to migrate your code from one to the other?

I migrated VSS to ClearCase. Our ClearCase was slow (local database but remote license server). There was a migration tool, but a test estimated it would take 6 months to run. So we did an export/import of a snapshot of the latest data, wrote a tool to recalculate which duplicated files should be linked/shared files, and didn't migrate the history. After the migration we kept the VSS database around while no longer using/updating it, in case we needed to refer to history.

Christopher Wells
Thursday, March 11, 2004

We are migrating from VSS to Surround SCM by Seapine Software.

We evaluated Vault but found that the features in Seapine's offering were better, and the performance was snappier.

Also the branch and merging had a more intuitive UI to all the developers on our teams...

With our repository, conversion in _any_ product - Seapine, Vault, etc, was estimated by their software to take 6 full days. We are opting not to do that [we don't think it will work anyway, what with corruption and all].

We're going to start fresh from a set of files, and just leave the old SourceSafe accessible if anyone needs history. In a manner of months, we'll be accessing the old repository less and less for historical information.

Rick Watson
Thursday, March 11, 2004