Scott Hanselman

CVS and Subversion vs. VSS/SourceSafe

April 8, '05 Comments [14] Posted in DasBlog | Tools
Sponsored By

Here's a response I gave to a fellow on an email list I'm on yesterday. He was having trouble understanding that CVS (and other source control systems) didn't "lock" files (checkout with reservation) as he has been a VSS person for his whole career. This is what I said (a bit is oversimplified, but the essense is there):

With VSS you:

Checkout with reservations – meaning that developer has an exclusive lock on that file.

With CVS you:

Edit and Merge optimistically – developers can make a change to any file any time. However, CVS is the authoritative source and they must Update and Commit their changes to the repository.

It sounds scary, but it’s HIGHLY productive and very powerful. It works more often than not, as most devs don’t work on the exact same function. It is largely this concept that makes Continuous Integration work.

It’s a FANTASTICALLY powerful way to manage source. No need to wait for that “locked” file. Source files can be edited at any time. For example, if there is a file with two functions:
 
Line1: Public void a()
Line2: {}
Line3:
Line4: Public void b()
Line5: {}

Two developers can edit the same file, different functions: 

Line1: Public void aChanged() <- DEV1
Line2: {}
Line3:
Line4: Public void bDifferent() <- DEV2
Line5: {}

These changes are called “non-conflicting.” CVS will automatically merge them. Now, we don’t know if they files will still compile (that’s the job of the developer and the build system) but since different lines of text are changed, they don’t conflict.

If two devs change the SAME LINE, then CVS holds both changes with “Conflict Markers” and demands that the developer RECONCILE the changes before committing. I manage all the dasBlog development worldwide using CVS. How could I do that if I allowed you in India to LOCK a file for days at a time? For example, when you are done working in your sandbox, it’s your responsibility to merge your changes in with the mainline.

From http://www.atpm.com/7.03/voodoo-personal.shtml

"CVS (Concurrent Versions System) is an open-source version control tool that’s extremely popular in the Unix/Linux world. CVS is a client-server system, which makes it easy for multiple users, possbly scattered across the Internet, to collaborate.. In fact, Apple uses it internally to manage the development of Mac OS X, and to make their sources for the Darwin kernel available to the world. CVS’s signature feature is its use of “optimistic” locking to let multiple people work on the same file at the same time. It then automatically merges their changes and signals whether it thinks human intervention will be required to complete the merge. (It seems like it would take magic for CVS to do this reliably, but in practice it has worked very well for me.) CVS (Concurrent Versions System) is an open-source version control tool that’s extremely popular in the Unix/Linux world. Unlike Projector and VOODOO Personal, CVS is a client-server system, which makes it easy for multiple users, possibly scattered across the Internet, to collaborate. Although only the client runs on Classic Mac OS and Windows, the server runs on Mac OS X. In fact, Apple uses it internally to manage the development of Mac OS X, and to make their sources for the Darwin kernel available to the world. CVS’s signature feature is its use of "optimistic" locking to let multiple people work on the same file at the same time. It then automatically merges their changes and signals whether it thinks human intervention will be required to complete the merge. (It seems like it would take magic for CVS to do this reliably, but in practice it has worked very well for me.)"

From http://www.xpro.com.au/Presentations/UsingCVS/Document%20Version%20Control%20with%20CVS.htm

"By default, CVS uses an optimistic multiple writers approach. Everybody has write permission on a file, and changes are merged as the editors commit their changes to the repository. Changes won’t commit without merging. At first, this protocol appears problematic to most people who haven’t used it. In practice, manual intervention is only required for lines which have been modified by both editors involved in the merge. As with file-locking, this protocol is not without risk. It is possible to introduce logical errors to a file which has merged without incident, as added or deleted lines can change the semantics of the prior version. This technique is most effective when changes are committed frequently and the number of simultaneous writers is minimised."

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Friday, 08 April 2005 16:19:05 UTC
But it's not true about VSS "Checkout with reservations – meaning that developer has an exclusive lock on that file."

That's just the default. Any REAL programmer (and that excludes the so-called experts who *recommend* exclusive checkouts, morons) goes in and turns on shared checkouts.

You can easily simulate a "CVS-style" model with VSS. We did it the whole time we used VSS (we're on Subversion now).
Friday, 08 April 2005 16:25:09 UTC
Darrell,

This is true, however, I've been REALLY underimpressed with not only VSS's merge functionality, but also it's branching and labelling. Also when our VSS DB hit 15GB and got corrupted weekly, we figured it was time to move on.

How many people really use VSS for large scale concurrent development? I wonder.

Also, you're saying you had no trouble at all, even with VSS-->VS.NET integration using a CVS-style model?
Friday, 08 April 2005 16:25:18 UTC
I'm not a SourceSafe apologist, believe me. It has lots of problems, I curse it often.

However, VSS has this feature too. Multiple people can check out a file, and when the second person checks back in it does a automatic merge and/or conflict resolution just like you describe. This ability can be turned on or off by the administrator, and at checkout time you can also exclude someone from checking out behind you (just in case you are doing extensive changes that are unlikely to be easily mergable).

Docs here:
http://msdn.microsoft.com/library/en-us/guides/html/vsurfidd_checkout.asp
Tim Farley
Friday, 08 April 2005 16:33:11 UTC
Apparently my "disclaimer" in the first paragraph wasn't strong enough: "a bit is oversimplified, but the essense is there"

Yes, I know VSS can do this, but I would propose that it is:

* not the default
* virtually unknown as a concept to "mort"

No?
Friday, 08 April 2005 17:53:13 UTC
First, I'll concur with Scott Hanselman. I've used VSS at many firms, managed by VSS rocket scientists, and this is the first time I've heard of VSS merge. If it's like anything else in the product, I'd be afraid it would corrupt the entire VSS database when it's turned on.

Speaking of which, reliability is the central core of this sort of activity. I could care less about VSS hidden features or the fact that it is free. That one essential thing is missing.

Given reliability, merges are a great thing. If you don't like what the system produces on checkin, just roll it back.

And a few last shots. Microsoft reps are now enthusiastically talking about the VSS rewrite for VS 2005. They don't say good things about the existing version. And way too many of us are making comments based on "my SCC is better than your SCC", instead of reliability and good feature sets.
Friday, 08 April 2005 18:20:34 UTC
FlexWiki wound up as a true open source project in large part because the exclusive checkout that GDN currently provides was so painful, it made it impossible for me to contribute. For example, some files were checked out for four months. So I agitated that we move to SourceForge, the primary reason being to get to the much saner model of CVS.
Friday, 08 April 2005 22:04:19 UTC
Is "mort" using an SCM at all?

That being said, I'm trying to convey the same ideas to a programmer that could in no way be labeled a "mort".
Friday, 08 April 2005 22:05:08 UTC
Whoops, damn sneaky return keys.

"mort" and making slow progress.
Saturday, 09 April 2005 02:00:00 UTC
Heh, I got a kick out of reading the quote from atpm.com. The way it repeats itself makes you wonder if they were using a CVS style version control system that performed an automatic merge. I wonder if the content that begins after the SECOND occurrence of "CVS (Concurrent Versions System) is an open-source version control tool that’s extremely popular in the Unix/Linux world..." was meant to replace the first part of the paragraph.

I'm not bashing anything. Just a joke...
Sunday, 10 April 2005 22:26:35 UTC
"Now, we don’t know if they files will still compile (that’s the job of the developer..."

Maybe you have the joy of working with better developers than I do. Last time I tried this model it only took a couple of hours for the code tree to get screwed up.

If only I had the power to fire people!
Monday, 11 April 2005 01:49:16 UTC
We have a 93GB sourcesafe database. Maybe we've been lucky, because we don't have/had any corruptions to the database.

The database is accessed by 30 developers + remote developers via SourceOffsite. We have multiple projects with multi-year timeframes, and a few projects that are 5 million LOC+. SourceSafe has not faultered much. We restored from tape backup _once_ losing about a days work.

Having said that, we are tossing SS for Subversion. We looked at Vault, but the migration was still too painful. We decided that we weren't migrating anything, and we'd start from scratch. Keeping the SS database, and all new development is done with Subversion.

Basically a cost decision. We're due to re-license, (Despite what most people think, it actually isn't free at all), and Subversion offers a comelling alternative for very little cost (some training, some management, some 3rd party integrayion tools), most of which we have to do anyways when new developers start who haven't worked with SCM tools before.
John
Wednesday, 13 April 2005 05:08:59 UTC
VSS lock-in mode is optional, admin can allow multiple check-outs. I haven’t used lock-in source control for decade. With multiple check outs, just as you say conflicted changes are rare, and VSS merges such changes automaticaly. You must have nerves of steel to deal with CVS “I don’t know what is a directory” wonderful legacy :)



The realy low point of VSS is not lock outs, its horrible performance over internet. Really bites when you have outsourcing team. Perforce w. Visual Studio integration is by far da best source control system I ever seen. Atomic check-ins are golden.
Max S.
Wednesday, 13 April 2005 13:37:38 UTC
What you use and whether you want to use exclusive checkouts depends on many factors.

CVS-type source control works because large (many developers), distributed development cannot use exclusive checkouts, period. It makes no sense.

However in a small shop with 3 or 4 developers sitting next to each other, exclusive checkout makes a *lot* of sense. Each developer is normally checking in many more changes per check-in (which makes merging more risky) and it's simply not a hassle to unlock an exlcusively checked out file (just shout across the room).

So I don't think you should say you're stupid for using exlcusive checkout.
Alan
Sunday, 24 April 2005 18:55:31 UTC
Well, when you commented on .Net Rocks recently that no-one comments on your blog posts, maybe some people took notice. This seems to be a healthy discussion here.

I'd like to move to Subversion, but currently my workgroup uses VSS, and we have turned on shared checkouts. There's no built-in merge, it will just display the differences, and you have to choose which to go with (manually merge). We only have 10 devs, so it works for this small scale. We have a lot of code, but this is not a _large_ code repository. I think VSS works for small stuff, but it can be annoying at times. VS.Net integration has been just fine for use.

As soon as I have some spare time, I'm going to install Subversion to explore it more.
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.