Subversion vs Visual SourceSafe

Following is a list of replies to my question regarding Subversion vs Visual SourceSafe on the Subversion mailing list. I asked this question at the end of 2003.
--- Eric Wadsworth (wadhome.org)


Here's a quote I once heard from someone who works at Microsoft:

    "Visual SourceSafe?  It would be safer to print out all your code,
    run it through a shredder, and set it on fire."

-Fitz

Brian W. Fitzpatrick    fitz@red-bean.com



I'll vouch for the crappiness of VSS.  It corrupts easily, and the tools MS
gives you to fix it, don't fix it. =sigh= It also gets very very slow as the
database gets larger.  No atomic commits.  You must lock files to edit them.
NO UNIX SUPPORT.  About its only advantage that we use is file "sharing"
between projects.  i.e. you update a shared file in one project, and someone
checks out the other project, they'll get the same version.

I'd even consider CVS over VSS any day.

A few comparisons:
http://www.perforce.com/perforce/reviews.html
http://better-scm.berlios.de/comparison/comparison.html

One in Italian, if you read it:
http://www.siforge.org/articles/2002/12/10-version-control.html

Sir Woody Hackswell [woody@hackswell.com]



Not a document, but I can tell you this: if you go looking for help with
VSS, you'll quickly find that there's only 1 (one) book ever written about
it (which is a couple of versions back and now out of print) and anyone who
will consult on VSS will offer the same first advice: "Get rid of VSS for
ANYTHING else".

VSS has big problems with repository corruption, and even MS recommends that
you keep repositories smallish. The repository fixer doesn't always fix
broken repositories.

It's pretty telling that Microsoft doesn't use it for the Windows source.

Mark

Mark [mark@msdhub.com]



But my view on VSS is pretty much on par with the previous few messages:
Avoid it like the plague. It corrupts its repository constantly.
Especially for remote workers. They use VSS at my day job (a 100%
microsoft shop) and its terrible. We have constant problems with it.

Anything is better than VSS. Keeping backup directories with no CM is
probably a better solution than VSS.

If Eric's organization is dead-set on a commercial product, I would have
to say ClearCase. But ClearCase is expensive and requires
constant network connectivity. Subversion is probably more appropriate for
a distributed environment.

L8r,
Mark G.

Mark Grosberg [mark@nolab.conman.org]



Many people will publicly decry VSS, e.g.,

   

I recall a site listing the top ten reasons not to use VSS, but I was
unable to locate it by search.  I have personally worked with VSS and I
must agree with the nay-sayers.  VSS is a data-loss bear-trap armed and
waiting to destroy your work.  I have been told that even Microsoft
does not use VSS internally.  I do not know if that statement is true,
but no Microsoft engineer with whom I'm acquainted uses it.

No matter what source code or configuration management system you
recommend, a vote _against_ Visual Source Safe is a vote _for_ safe
source.
__________
Scott Collins 



One advantage (only one I can see) is that VSS manages binary files well,
i.e. it has exclusive locking.  For this reason I would choose it over CVS
or subversion at this point, though SVN will have it after 1.0.

CVS has advisory locks, but might not be what you want (I know I don't)
for a large organization.

If you have binary data, be sure that your source control can manage it.
Exclusive locking is nessesary to prevent two people updating the same
file at the same time - which then requires they hand merge changes.  This
is really really hard for some data formats (3d models with animation,
texture mapping, etc.. for example).

Kevin Meinert [kevin@vrsource.org]



> waiting to destroy your work.  I have been told that even Microsoft
> does not use VSS internally.  I do not know if that statement is true,
> but no Microsoft engineer with whom I'm acquainted uses it.

this is true, and IMHO a good reason not to use it.  There are lots of
buggyness, especially with integration of VSS and MSVS.  If they were
using it, it would become a good tool.  And there is probably a reason
they don't use it.

They use something close to CVS (a command line tool).  called squish or
something I can't remember.  but I had a friend show it to me once when I
was at microsoft visiting.

Kevin Meinert [kevin@vrsource.org]



I'm relatively new to using subversion (for a small startup of mine) but I have
and continue to use VSS in my day job. Hence my choice of subversion for my own
use.

The best thing about SourceSafe is the price.

Everything is else terrible.

We've nearly 2 million lines of source (C++ and VB6) in our main repository and
about 20 developers. I've had to extract and rebuild the whole repository three
times in 2 years. Each time losing 6+ months of history.

It's slow and the 'analyze/compress/repair' functionality does not seem ever to
compress and recover space. The corruption is terrible. We've gone through
periods where we'd lose several files each day.

Marc Leith
marc@mleith.net



> The best thing about SourceSafe is the price.

Heh :-).

Well, since this is the Subversion users list: The only way SourceSafe
could beat us on price is if Microsoft pays you to run it.

kfogel@collab.net



Here's my list of "why I hate SourceSafe".  With the noted
exceptions, Subversion gets all these things right.

# lack of atomic checkins

# generating a history list is agonizingly slow

# "shared files" are a kludge.  If you edit one, and don't realize
  that it's shared (i.e., that there is a a second copy of it lurking
  somewhere on your disk), you now have an internally inconsistent
  source tree.  To be fair, though, Subversion supports neither "hard"
  nor symbolic links; they merely mumble that they plan such support
  after the 1.0 release.

# it can't be used remotely without something heavyweight like VNC or
  VPN

# it can't be used from Unix (although, to be fair, last time I tried
  it with wine, it worked fine)

# there's no way to ask "what changes have I made".  You can see how
  your working copy differs from the current version of the
  repository, but if someone has checked in changes since you did "get
  latest", you'll see diffs between your stuff and that, not just the
  changes you made.

# And comparing your working directory with the repository (as above)
  is even more agonizingly slow than generating a history list

# You cannot add a label to a point in the past; you can only label
  the repository "right now".  And who knows what might change while
  the label is being applied; there's no guarantee of atomicity.

# You cannot delete a label; you can only change its text.

Eric Hanchrow [offby1@blarg.net]



One of the ways to show the problems with sourcesafe is to look in the
Microsoft knowledge base for them Search for "Visual Sourcesafe kbbug"
or "Visual SourceSafe corruption" that should help you wilth reasons
not to use.

Point out that all databases MUST be analysed frequently, once per day
if the DB is busy. We ended up writing a utility to drive analyze.exe
automatically and check the logs for evidence of analysis failures.
We had around 80 VSS DBs so the tools where a necessity, Leaving this
up to IT people to do manually is asking for trouble.

Why 80 DBs you ask? Once the quantity of data or files or revisions
(its not easy to predicting the failure points) get big the DB will
failed frequently. MS use a rule of thumb of 2GB, but you can see
problems at smaller sizes.

If a client machine loses its network connect while working on a DB
it will corrupt. Plug the LAN cable or hit the power switch.

We hit problems with the automation interface and got as far as the
Redmon VSS support team only to be told that they would not fix it.
You cannot retrieve old revisions of software if you later deleted
a file in the old label from automation. This means you have to
use the command line SS or manually do all source control.
Processing history from the automation API takes around .5 seconds
per item on a LAN. So a file with 50 revisions will take 25 seconds
to list.

If you have virus protection running and it checks the files on the
VSS DB share performance will dive by a factor 20x.

All machines that touch the DB must have their time synchronized or
you will see labels fail to label the files you expect.

They said that the energy was going into a SQL based replacement,
I have no idea where they have got to with it. And as others have
said MS does not use VSS in house.

You might also like to point out that running the VSS GUI is unusable
on slow connections. A right click on a file in the GUI transfers
5M Bytes typically before the menu appears.

Barry

Barry Scott [barry@barrys-emacs.org]



VSS tends to get picked because people have used it, and departments 
have licences for it already (I think you get bundled licences with 
various bits of Visual Studio). I think it's pretty useless, don't like 
the enforced exclusive locking (plenty of going to ask other people to 
unlock files you want to work on) and never used the integration anyhow 
(was doing Java).

The most fun thing I've found is that if you set the clock on your 
client PC forward a week, then commit a change, no-one else will see the 
change until next week. Nice. Logic-timebomb anyone?

Mike.
Mike Mason [mgm@thoughtworks.net]



How about this? When I first saw that I was shocked
and threw away vss immediately. Took some time
to convince my boss - until he saw that warning himself.

(Note: this screenshot is from about three years ago.
I don't know if newer versions of vss still do that)

Screenshot is here:
http://wadhome.org/MicroSoft.jpg

Stefan
SteveKing [steveking@gmx.ch]



As a side issue, at my work we are moving away from VSS over to Subversion 
(clients on Windows, server on OpenBSD using Apache). Actually, all our 
development and content material is now on Subversion, with very frequent 
backups. Up front we decided that some loss of commit history was not that 
critical (we're pretty small company), and the old VSS DBes (now locked) 
was/is still available for the curious.

/Sigfred
Sigfred Håversen [suselist@mumak.com]