Fog Creek Software
Discussion Board

CVS vs Visual Source Safe

Hi I am trying to figure out which product to choose for our versioning and source control. Our dev team is comprised of 3-4 developers and we use mainly ASP and VB.

Any insight, suggestions and hints are highly appreciated.


Thursday, November 21, 2002

If you haven't done, look at the archives (don't forget the Search button on the left of this board)

Robert Chevallier
Thursday, November 21, 2002

I'd take CVS any day for a whole host of reasons:

1. It enforces the use of the system so that the team derives some minimal level of benefit from using source control.  I've seen too many shops that use VSS with multiple checkouts disabled, rendering VSS nothing more than a fancy locking fileshare with a bad UI.

2. Transparency & Reliability.  CVS stores all of its data (source files and subsequent diffs) in plaintext, which gives me more peace of mind than VSS scheme of storing *everything* in one monolithic database file.  The same relationship exists between unix mbox files (plaintext, reliable), and Outlook mail databases (after losing two of them within weeks of each other due to corruption, I stopped using OE).  I've heard that database files don't have corruption issues in VSS 6, but I'd rather not take the chance, thanks very much.

3. Diff functionality.  Sure, you can choose from three different diff "styles" (VSS, unix, and semi-visual).  However, the VSS and semi-visual modes are pretty sad-looking, and not very useful to boot.  Futher, you cannot specify an external diffing tool, which can be done in many CVS clients.  This leads to huge pains when getting into integration phases between branches, etc, which brings me to:

4. Branching functionality.  As far as I know, VSS cannot branch and merge entire projects, which is a major hassle, especially on larger projects.  This makes it very difficult to use VSS with larger teams where (in CVS) a new branch is typically created for each "module" of functionality for each subteam.

5. Choice of clients.  If you use VSS, you use THE VSS client.  If you use CVS, you have dozens of clients to choose from, each with different strengths and weaknesses.  Of course, there are IDE's that integrate with VSS to allow you to check in / check out files, but you still need to go back to the VSS client to perform management functions.

Chas Emerick
Thursday, November 21, 2002


I'm no huge fan of VSS but there are some factual errors in your post.

2. VSS does not store its database in one file, it stores it in thousands of small files. The one time our database got corrupt here we were having terrible network problems and it was limited to a few source files, the rest of the database was fine. No data loss.

5. We use several different VSS clients at my company: the traditional VSS explorer, Visual C++ and Visual Basic, SourceOffSite from SourceGear and the command-line client for build scripts. SOS also integrates w/ VC and VB.  I actually never, ever use the VSS Explorer client anymore and just use the SOS client since I work on a laptop and work from home a lot. It is just easier to use the same one all the time. Downside is that SOS costs money where CVS is free.

3. While VSS Explorer doesn't let you pick your diff program, the SOS client does. I use the lame WinDiff or VSS Diff but there are some other great differs out there like Araxis Merge that are supposed to work fine w/ SOS.

Like I said, VSS is no picnic and if VSS wasn't already in place before I started working at my place I would have pushed for CVS. But I just wanted Nicholas to have all the facts.

Thursday, November 21, 2002

I will repeat what I said on one of the earlier threads on this topic.

I've been using VSS for about 7 years, I've never, ever, lost any work, nor has anybody on any team in any business that I've ever worked with.

Most VSS problems are user error, in my opinion.

Thursday, November 21, 2002

Alberto, maybe you haven't lost source because of VSS, but I did.

I was doing a check-in and, during the process, the network disk filled up. VSS didn't handle it properly and only kept 1/2 of one of the file. Since it automatically goes a 'get' of the file after checkin, it also overwrote my version with this truncated file.

Unfortunately, I was also the only developer on the project so no one else had an older version on their machine... It took several days to re-create that file properly.

Yes, the network guys fell down on their jobs (full disk, no backups), but VSS should have been able to recover from that error without data loss.  When my boss called MS to complain, he was told that there was a patch available to fix this problem. When he asked if there were any other patches available, the rep told him that he was only allowed to give patches out to people who called with specific problems...

Thursday, November 21, 2002

Use the one Microsoft uses.

Microsoft is a great believer in excellent practice of eating dogfood (using the software they are developing).

However they use VSS for only a few small projects.

They use CVS for all their large or important ones.

Make of that what you will

Anonymous Micro-serf
Thursday, November 21, 2002

Use CVS, under Windows get TortoiseCVS  and it becomes simple to use.


Gregor Brandt
Thursday, November 21, 2002

Are you sure MSFT uses CVS? Check your sources. I agree that VSS isn't widely used, but nor is CVS. They have their own tool.

As for VSS - I've been using it successfully now for several years. No loss of data or corruption. However, if corruption does occur, it's a pain to cleanup. I had heard that future versions would employ SQL Server. The one I use, v6, uses zillions of individual files.

As for clients - my editors interface directly with VSS - and do a great job. The most recent tool (and now my clear favorite) that works beautifully with VSS is IntelliJ's IDEA 3.0 editor for Java. One sweet IDE.

CVS clearly has lots of strong features. If your projects require cross platform development, VSS won't cut it. But, we do all our Java work on Windows and move our jar files to Linux. So, having something that ran on anything other than a Win32 client wasn't a requirement.

Another nod in VSS's favor for small development teams that do everything on Win32 is that it's much easier to setup and administer than CVS.

But, just like desktops and operating systems - it all depends on what you like. They're both good.

David Geller
Thursday, November 21, 2002

Since when has Microsoft used CVS? They used an internal descendant of some commercial product for a long time (SLM), some groups have used VSS, most groups probably use something else (SourceDepot) now which is, along with a few little auxilary tools, pretty damned good. I think it's a descendant of something commercial.

One reason they use these customized tools is that a few projects have hundreds of developers working on them.

More from this group:

Thursday, November 21, 2002

The only problem with CVS and VB, is that VB stores its forms in binary files.  This makes it impossible to do merges on form changes.

I'd still use CVS for VB, but I'd make it mandatory to use the edit/noedit feature of CVS.

Gerald Brandt
Thursday, November 21, 2002

I've never heard of Microsoft using CVS on any project and I work there. Perhaps some of the researchers in MSR use it and that's why but I've never seen or heard of any product team using it.

Thursday, November 21, 2002

All of the teams I've worked on here at Microsoft use Source Depot now (which is a descendant of a commercial product, whose name I can't recall).

I've used CVS and SD extensively and honestly, I'd use SD over CVS any day.  Far less error prone, in my experience.

That's just been my experience.

Another Anonymous Microserf
Thursday, November 21, 2002

VB doesn't store its forms in binary.. here's the source to a basic .frm file:

Begin VB.Form Form1
  Caption        =  "Form1"
  ClientHeight    =  3195
  ClientLeft      =  60
  ClientTop      =  345
  ClientWidth    =  4680
  LinkTopic      =  "Form1"
  ScaleHeight    =  3195
  ScaleWidth      =  4680
  StartUpPosition =  3  'Windows Default
Attribute VB_Name = "Form1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
Option Explicit

Thursday, November 21, 2002

Microsoft uses perforce, aka SourceDepot.

Thursday, November 21, 2002

Microsoft never used CVS. They had a inhouse system call SLM ("slime" Source Library Management).

I have used VSS and it blow chunks. Using it over DSL would corrupt the the VSS repository nearly everytime. And VSS has no sane way to handle branching (or merging of branches) like Perforce does.

Thursday, November 21, 2002

Microsoft uses SourceDepot which happened to be the name of the product currently known as Perforce, in fact if you run strings on Perforce 4 binaries you can see it's former name there.

Beka Pantone
Thursday, November 21, 2002

One reason they use these customized tools is that a few projects have hundreds of developers working on them.

What about the linux kernel? ;)

And they're starting to use Bitkeeper, and they seem pretty happy with it (more and more modules are starting to use it, too).

Anyone has any experience with BK?
Myself, for my own, personal, projects, it runs fine (and no server setup for simple tasks like those, so it's a blessing :)

Thursday, November 21, 2002

VB SUCKS.. and it just so happens that Mooney is WRONG too!

Visual-Basic v5, & v6 (but !.NET) will create a binary "FormName.FRX" file for every "FormName.FRM" file in the project depending on what type of controls you actualy place on the form!

If you place any OLE (ActiveX) or COM object control onto a form and save the project, VB will create a new form file with the same name as the form but with the extention ".FRX" after it.  This holds binary information that can not be put into the .frm file. 

If you look closesly at the form resource code,  you will see binary (byte) offsets for the exernal ActiveX control data located in the binary .frx file. 

This can create HUGE problems whenever the two files get out of sync.. And trust me.  it can happen often, even with VB6 (sp5).  The VB6 IDE is VERY buggy when working with medium to large size projects. The pcode (and native) compiler even crashes on me some of the time. (legacy bugs the MS refuses to fix now that VB.NET is out)

I have a project that has about 15 forms... ever one of my text based .frm files has a binary .frx file because i have ActiveX contorls on my forms (for high-speed custom graphics).

All of these binary files make team development with VB difficult and also makes branch and merging improssible.  That is why i use PROJECT SHARING and PINNING in VSS when it comes to VB6 projects. But i'l save that lesson for another day ;)

Now.. in terms of revision control software...
I currently use VSS6, but will eventually be switching over to CVS-NT. (thanks Gerald!)

If I was to pay for a Revision Control tool, I would buy Perforce on the spot.... i would also consider looking at BitKeeper

Final Notes:
P.s.:  VisualBasic SUCKS! Always have.. and Always WILL! P.s.s: Like Joel says.."Skilled C++ programmers make for great VB programmers, but that fact along doesn't change the reality that VB will always SUCK!

Heston Holtmann
Friday, November 22, 2002

The interesting fact about Perforce is that is does transactional updates for a bunch of files and not for each file in sequence like CVS. Ever been in the middle of a huge commit and have the network going down ? Good luck if you do not tag the fileset every now and then...
CVS *can* end up semi-committed.

Philippe Back
Friday, November 22, 2002

"VB SUCKS!"? Is that true? Well then, good to hear. Congratulations on boiling down such a complex topic as "language nuance" to two words. You truly are an intellectual giant!

There are definitely issues with Visual Basic, but there are issues with every language. But to label something as “sucks” only tells me that you have no idea what you are talking about. There are thousands of applications written in Visual Basic in use today. Many of them are mission critical applications. That tells me that a large number of people were successful in deploying a VB solution. I think it might be you who has the issue, not Visual Basic.

Friday, November 22, 2002

Perforce ( ) is an excellent tool. One nice thing about it, its free for the first two users. That makes it really easy to test out. The downside, its gets expensive as you add users (around $700-750 per user).

QSC ( ) makes a less expensive product called Team Coherence ($ 249 for 5 users, $219 each additional user). There were a few key thinks I really liked about TC; it works over a WAN (unlike VSS that needs extra tools), it integrated with Visual Studio seamlessly (the only one I’ve seen as well as VSS), and it has a solid GUI that actually makes sense to use.

I’m going to need a purchase a solution myself, and I think I’ll be going with Team Coherence. We currently use a product called Roundtable (very nice product), but it only works with a single language (Progress 4GL).

Hope this helps.

Friday, November 22, 2002


Sorry, I woke up feeling really cranky, so I'll try to tone it down...

Anyhow: "Mission Critical".  I hate that term.  Any application which you sell for money is misssion critical, because if it fails, your mission will fail.

Some missions are more critical than others: ones that involve human lives, of course.  Transportation, life support, you know the drill.

Software that I write is supports entertainment.  If it fails, someone won't get to watch Monday Night Football, perhaps.  Planes won't fall from the sky, but our company would suffer.  Our mission isn't critical, but the software is critical to our (non-critical) mission.

Where was I going with this?  Oh yeah, there isn't any reasone why deployed software should not be damn near perfect.  So isn't mission critical software anything other than internal tools?

Nat Ersoz
Friday, November 22, 2002

As it happens, here is some info on the SourceDepot system:

Just me (Sir to you)
Friday, November 22, 2002

Can I suggest that if you are working under Windows and want a very easy to use, very easy to implement and very reasonably priced VCS you take a look at QVCS from

Neil Butterworth
Friday, November 22, 2002

Forget CVS, forget VSS, forget Perforce, try NXN alienbrain.  Very hip, very easy to get into, great features for e.g. smart branching, I found nowhere else ... costs about same as Perforce ...

John Glatt
Monday, December 09, 2002

"But to label something as “sucks” only tells me that you have no idea what you are talking about"

Unless it *really* sucks :-)

Daniel Daranas
Tuesday, March 30, 2004

Well, let me just add that Alienbrain sucks.  *Really* sucks.  I swear to you, we would have been better off had we not used any source control at all.  We have *all* lost code to it, and we only have 3 programmers!!

We have called them numerous times and it really appears that they have no idea how source code control is even *supposed* to work!  It is bad, bad, bad!  Does any professional team use it for source code?  (It was originally an art tool, as I understand it, and it should have stayed that way.)

On the other hand, if you like a hundred pop-ups each time you try to get latest, half of them asking if you want to merge (always say "yes to all"), and the other half asking you if you want to overwrite all of your changes (always say "no to all"), then be my guest...

Alienbrain is *unusable*.

just some guy
Monday, May 24, 2004

I have to comment on the above post recommending QSC Team Coherence. 


It does have a nice simple user interface.

It's been running for nearly three years now with no sign of corruption.


It seems to crash semi frequently when used with the Delphi IDE integration.

If you've had it open all day it usually generates an access violation when closing down.

When checking differences between your workfile and the most recently checked in file sometimes some very strange things happen.

Branching isn't obvious and you have to be quite paranoid if you don't want to lose any work.

In short we're starting to look for a new version control system.

Giles Roberts
Tuesday, August 17, 2004

*  Recent Topics

*  Fog Creek Home