Fog Creek Software
Discussion Board




VSS and/or CVS?

The choice of ONE "source code management system" for ALL the future development is quite an important decision with a long-term impact. In my case, I consider using one of these: Visual SourceSafe or CVS.

VSS because:
- in many cases, you'll get it for "free": If you're Microsoft Cerified Partner, msdn Universal subscriber etc.
- it integrates well with (mostly used) Microsoft development environments
- it's scriptable with VBScript

Reasons for CVS:
- It's not "free", but it IS free.
- CVS is said (especially open source advocates) to be cool (Joel uses it too). It's used and it proved itself in rather big projects (e.g. Linux).
- It's also polished in many iterations (because developers care about the tools they use. Read <a href="http://www.joelonsoftware.com/articles/fog0000000012.html" target="_new">about dog food</a>.)

Currently, I'm using VSS (for the reasons mentioned above) und I know there's a lot of VSS-bashing all over the place. "The files get lost" is one of the most common arguments I hear against VSS but I haven't expirienced it yet after three years of extensive using it in diverse projects and source tree size of the last project I still work on bigger than 1,3 GB (and getting bigger every day ;))).

On the other side, the argument against CVS is, as some voices in the industry say, that it is slow. I also don't know, how well it performs on NT, if it's scriptable with e.g. VBScript, how well it integrates with Microsoft tools?

Besides, what's your expirience with VSS' "lost files", CVS' "slowness" and any other known issues concerning these two tools?

(NOTICE: As far as Microsoft and Open-Source are concerned, there's possible clash. That's why I hope that this won't start another "war" between MS and Open-Source people. This forum was always free from that kind of discussion so let's stay reasonable.)

BM
Thursday, November 22, 2001

The fact that many teams at Microsoft don't use VSS is a pretty bad sign...

If you have a huge code base and are looking for better performance than you can get with CVS, check out Perforce.

Joel Spolsky
Thursday, November 22, 2001

On the other hand, there are some teams at Microsoft that do use VSS rather than CVS, and do so successfully. I can't name names (those pesky NDAs), but I did deal with multi-gigabyte source trees while contracting there.

In my experience, the "lost files" and "database corruption" issues were pretty well fixed with the switch to a new file format in VSS 5 (current version is VSS 6.0c).

Other things to consider: if you're ever going to need to do SCC over the Internet, there's only one third-party solution (SourceOffSite) for VSS, and I've seen mixed reviews of it.

You also need to think about this in connection with your other tools -- editors, documentation tools, whatever. Which SCC interfaces do they support? Which products are they tested with?

Mike Gunderloy
Thursday, November 22, 2001

We used VSS for years and gigabytes.

Be religious about running analyze.exe (e.g. once a week if you can't run it more often), and about backing-up "last-known-good" copies of the database, because if the database does become corrupt and if analyze can't fix it, then you're out of luck: VSS uses some proprietary format which only VSS analyze knows how to try to fix.

Some operations (e.g. deep history) take a while to run.

Files became corrupted when their size exceeded some limit (100 MB or something like that): file sizes can be large if you store builds (*.exe/*.dll/*.pdb) in VSS, where file size means 'current file and all its history'; you might like to switch of history for these files, if you store them in VSS and if you do frequent [re]builds.

Integration of VSS into the DevStudio IDE doesn't work if you 'branch' a project: Devstudio checks-out from the mainline instead of from the branch. I switched off Devstudio IDE integration because I like to know exactly which files I'm checking out.

Christopher Wells
Thursday, November 22, 2001


Independent of the tool choice (CVS or VSS).

I still wonder why so many companies (inc Microsoft) have not settled on standard "CM" tool solution.
I guess it avoids them worrying about exit strategies :-)

I can only assume that sharing/integrating across divisions is a real pain in the neck.

NaC
Thursday, November 22, 2001

I have used VSS for about 6 years now, I have never, ever lost a file. Nor has anybody on any team I have ever worked in. I've heard of others losing files, but frankly, I'd back user error rather than software error anyday.

Some aspects of VSS are not strong, i.e branching, merging, but as a basic source code version control application I've found it to be solid.
I've heard of problems with different server/client versions running, but generally its worked really well for me - even saved my backside a couple of times :-)

Tony McConnell
Thursday, November 22, 2001

If you are in a multi platform environment then CVS _can_ be simpler to implement.  If you need secure connections to the CVS server though then you also need to get into implementing ssh, the secure shell, as well.

This is simple on *nix, a pain on Windows/DOS and OS/2.

VSS is simplest on MS only developments, I use it for my Visual Fox development.  However, its branching control is abysmal to administer, CVS, once you've got your head round it, is much more straightforward.

Simon Lucy
Friday, November 23, 2001

When I worked on Microsoft's Windows NT team, we used a home-grown system called SLM (Source Library Management). From what I've read, the NT team has moved to Perforce. I knew some teams that used VSS and they always made fun of it.

I then worked at a small company that used VSS. I liked its GUI, but we had many file corruption problems. In particular, accessing VSS over the company VPN using Windows 2000 would practically guarentee corruption.

I now work at a company which uses Perforce. I really like it. We haven't had any file corruption problems (that I'm aware of). It does seem pretty slow, though. I have also had some problems when Perforce tries to "auto-resolve" file diffs. Fortunately, these are small problems compared to VSS file corruption!

Chris
Saturday, November 24, 2001

CVS is the de facto standard among open source projects.

Have look at the FreeBSD tree for example:

http://www.freebsd.org/support.html#cvs
http://www.freebsd.org/cgi/cvsweb.cgi

The Mozilla code base is huge as well.
They also combined the cvs repository with an automatic build system for their various platforms which can track down what and whose source commit broke the build (cvsblame tool :)

http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey

Both projects use the feature that each cvs command can trigger a script. This allows for automatic routing of commit logs to various news groups and to cross links to bug tracking databases.


It is perfectly possible to use cvs on Win32 systems as well. Use the cvs and ssh ports from the Cygwin distribution

  http://sources.redhat.com/cygwin

There is a Windows GUI available as well for those who don't like the command line (search for WinCVS on Google).

The only problem I have watched so far is when clever Win32 programmers avoid ssh usage ("I don't want to type a password) and rather start to access the cvs repository via a samba mount, which means that they cross the Win32/Unix border without proper CR-LF/LF translation which might lead to additional CR's occasionally in the sources, depending on how their drives are mounted as text or binary for Cygwin. Sigh.


Repository duplication is handled much faster with cvsupit. But this has not ported to all major platforms yet.


Right now a group of programmers is working on a successor to cvs: subversion

http://subversion.tigris.org

Some of the original cvs people are involved.
Progress is watched by other players as well, like the Bit Keeper lead.


What I like about Perforce is that seems to organize diffs rather around logical transactions than file changes.
Systems like RCS/MKS/CVS show you what files were changed, and then you have to figure out why they were changed. It would be nice to see the why and then the files. (Which can be achieved by just watching the commit log flow, if people would stick to write useful commit logs, which often not happens in companies :)

Marc van Woerkom
Saturday, November 24, 2001


"Mixed" reviews of SourceOffSite?  Can you cite sources?  :-)

I will concede that the quality of the SourceOffSite user experience is somewhat constrained by the limitations of VSS.  Those limitations are in fact real, although often exaggerated.

I'm just standing up to defend our product.  We've got about 40,000 users, the vast majority of whom seem to be very happy.  :-)

Cheers,

--
Eric W. Sink
http://www.ericsink.com/

Eric W. Sink
Saturday, December 01, 2001

SourceOffSite gained a fairly bad rep for a while there until you guys fixed the W2K memory leak. The server was locking up on us every couple of hours until the fix. We actually had to write an app that monitored the service and restart it if it's memory usage went crazy.

I suspect it'll take a while for SOS's reputation to recover.

Chris Tavares
Sunday, December 02, 2001

VSS default locking hinders distributed development.
And: I survived three VSS repository crashes in less than six years.

CVS has many problems, too, from architectural weaknesses over speed to line-ending problems in multi-platform/multi-tool environments. But it makes up for this with two strengths:
- Reliability and robustness.
- Merge instead of lock.

There are now better choices than these two:
- Arch (my personal favourite: clean architecture, small, efficient and free)
- Bitkeeper (top-notch)
- Perforce
- PVCS
- Subversion
All good with Bitkeeper leading the pack of the commercial products.

Best wishes!

Peter Christoph Alexander Bär
Monday, October 27, 2003

Subversion.

It's 2004 now and Subversion appears to work really well.
It works like CVS (I use the Windows clients TortoiseSVN and AnkhSVN) but is much more efficient (using diffs on binaries) and fixes a couple of serious CVS annoyances.  Most importantly for me, Subversion I can rename files and every commit gets a revision number.  With TortoiseSVN reverting to a particular version and merging in changes is a breeze.

Reinier Post
Monday, July 26, 2004

I have been using VSS for over 3 years without any corruption problems, infact with the same project. I find it very easy to use with its wonderful interface and easy to integrate with MS products. Not very sure with other products getting integrated with Studios... :)

sNeelamraju
Friday, August 13, 2004

*  Recent Topics

*  Fog Creek Home