Pragmatic Version Control Using CVS

jarich (Jared Richardson) writes "Many people will remember Andy Hunt and Dave Thomas's The Pragmatic Programmer (Slashdot review) as one of the better books on real-world best practices. It was a watershed book for many developers. However, The Pragmatic Programmer assumed a certain level of familiarity with some of the basic tools of the trade. For many readers, this simply wasn't a valid assumption, so Andy and Dave have started on a set of prequels to PragProg, called Starter Kits." Richardson reviews below that series' introduction to the Concurrent Versioning System, better known as CVS. Pragmatic Version Control Using CVS author David Thomas and Andy Hunt pages 159 publisher Pragmatic Bookshelf rating 10 reviewer Jared Richardson ISBN 0974514004 summary A hands on CVS introduction and tutorial,

What's the approach? The philosophy of this series is summed up on the Starter Kit website:

Software development is difficult enough; if you try to build on a shaky foundation it can make development almost impossible (which might account for the fact that about 50% of all software projects fail). You need a firm foundation: The Pragmatic Starter Kit is a set of basic, common-sense practices applicable in all software development environments. The techniques given in these three books are not expensive to implement and are not hard to learn, but can make the difference between being a success and being a statistic.

The first book in the series covers the what, why and how of software versioning, using CVS for the examples. It walks you through installing CVS clients, setting up your server, and using basic commands, then teaches advanced concepts. It is the new CVS handbook that can be used by both beginners and veterans.

Target Audience This book, like The Pragmatic Programmer, should have very broad appeal. It should be required reading for any junior developers or CVS administrators, and it should be a bookshelf reference book for mid-level to senior developers. It is slanted heavily towards CVS, but given that CVS is free and widely used, that shouldn't prevent anyone from using the book to learn the concepts, even if their company uses another versioning system for production work.

What's to like? As is usual for Thomas and Hunt's books, this one is a very easy read. The concepts are clearly laid out, with plenty of working examples throughout. There is a good coverage of the fundamentals as well as very advanced topics. Unlike most CVS books or tutorials, this text is clear and straightforward. It's easy to understand and follow. It's got the best coverage of CVS branching and merging that I've ever read!

What's to hate? Honestly, there is not a lot here that I don't like. The introductory chapters are little too basic, but since the book is (partly) aimed at beginners, that's okay.

Why bother reading this book? I've been using CVS for over six years now (including being the CVS admin at two companies) and this book covered a few very useful advanced topics that I had never even heard of. An example of this is the use of vendor tags (Chapter 10). Using this feature, you can have a local copy of your favorite open source project in your company's CVS server and make changes to it. You can then merge your local project with the new releases of the public project, and CVS will handle merging your changes with the public baseline. This feature is incredibly useful, but I didn't even know it existed until I read this book.

This book is a great introduction if you've never used a versioning system. By the time you've finished the book, you'll have installed CVS (client and server), created projects, created new files, merged changes, etc. If you already use versioning software, it can remind you about the features you've forgotten about (or never knew existed). This book is a great introduction and a great refresher too.

Where to buy?

Not so long ago in another Slashdot article, Andy and Dave suggested that in order to compete in the new global economy, we should all diversify our skill sets. To that end, this book is published under their new publishing company, The Pragmatic Bookshelf. You can buy copies from the Pragmatic Programmer's web site in both dead tree ($29.95) and PDF ($20.00) formats.

Summary As we have come to expect from Andy and Dave, this is another great book. The technical content is rich and clear but it won't put you to sleep. It has appeal to both newbies and veteran developers. I give it '10 out of 10 slashes.'

Richardson met Hunt while he and Thomas were finishing up The Pragmatic Programmer and has reviewed each book that they have written since -- he makes no bones about liking their work.

Comments

CVS good, ClearCase bad

[pcraven]

CVS is great for version control. Don't get tempted by Rational's ClearCase product.

A full build of a sample project with CVS takes me 30 seconds. CC takes 7 min, 30 sec.

CVS doesn't need multi-site repositories, clearcase does if you have a lot of remote development.

CVS doesn't integrate with the kernel, so if CVS crashes it doesn't take your whole machine.

CVS has better add-on GUI tools for branching and comparison.

It is easy to create and apply patch files with CVS, something not easy to do with CC.

With CC, when you check out a file, you can't actually write to it. You have to loop and keep checking for the file to be 'writable' after check out. Even then, sometimes when CC marks the file as writable, it really isn't.

A batch update in CVS is easy, with CC you have to check out individual files. I have a script for this. A batch update takes about 20 minutes compaired to 45 seconds in CVS.

CVS is free.

CVS doesn't require as much training or support time as ClearCase.

ClearCase does have excellent command-line tools. It also has a lot more features. But you can probably live without them.

Shoehorning CVS to work with good dev practices...

[cduffy]

is a heckuvalot of work, and not something I'm really sure is worthwhile -- particularly with the variety of alternatives available.

Aegis, GNU Arch (my personal favorite), Subversion, BitKeeper... all of these work around CVS's worst failings. What's unfortunate is how few people have had their expectations of what a revision control system should do set far too low by CVS.

A few examples of features one should expect of a modern revision control system:

• Easy branching - Branching and merging in CVS is a royal PITA, especially remerging branches which have had some changes mutually applied. CVS has a number of other design bugs related to branching -- for instance, files added on a branch suddenly show up on the HEAD when they shouldn't -- that need to be worked around, sometimes painfully.
• Corruption-resistant repository formats - Because CVS rewrites the ,v files every time a change is made, a CVS server that crashes in the middle of an operation can cause data loss. (Not all of the alternatives are better -- a few years back, for instance, the BitKeeper installation at my workplace had a tendency to corrupt its repositories at well. BitKeeper, however, can at least detect corruption -- in the case of CVS, it's often never picked up on 'till one tries to check out a particular old version. Arch avoids the whole issue by never rewriting or removing files which have been added to the repository, as well as supporting md5sums and cryptographic signatures in the 1.2 branch to detect either low-level corruption or malicious tampering).
• Changeset orientation - Actually checking in a set of related changes as one changeset, and attaching metadata (log entries and whatnot) to that complete set. This also makes CVS's "tagging" very cheap -- instead of needing to record the revision number of each file in the repository, only the changeset number of the repository need be tracked.
• Intuiting revision control history - A number of tools such as cvsps and cscvs (the latter which I help maintain) will analyze a CVS repository's history and break it down into changesets. This information can be used for a global "who-did-what" or the repository as a whole (whereas in CVS one can only view history for an individual file without extra tools), for importing a CVS repository's history into a changeset-oriented revision control system (most of cscvs's users use it strictly for CVS->Arch conversions), and the like. With CVS, this is a time-consuming and error-prone operation; much of the information just isn't stored on the server at all, so the tool being used needs to try to figure it out. Merges are even worse -- there's no metadata whatsoever available in CVS to distinguish a merge from any other commit, which makes a nmuber of advanced merging algorithms impossible. A modern revision control system, on the other hand, stores all this information up-front; there's no need for the error-prone and tedious process of having some 3rd-party tool intuit it by looking at the revision control history for each individual file.
• Automated testing - Having a test suite that automatically runs on every proposed commit is next to impossible to do accurately in CVS (as there's no good way to figure out which changes need to be grouped together into a test run), and CVS has no way to prevent a commit from happening until some external test has been run. Aegis, on the other hand, has this built in as core functionality, and Arch makes it trivial to script when using the available patch queue manager tool, tla-pqm.
• Distributed operation - This isn't often a dealbreaker in commercial environments, but it's exceedingly useful doing Free Software development; indeed, Linus has said that he'll under no circumstances consider switching to a revision control system without it. A system with distributed repository support (such as Arch, or BitKeeper -- Aegis has rudimentry support, but it's error-prone, while Subversion has none at all) can allow 3rd parties to crea

Online CVS reference

[jpkunst]

Open Source Development with CVS by Karl Fogel is a great online CVS manual and reference. I use it all the time.

JP