Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Programming Books Media Book Reviews IT Technology

Pragmatic Version Control Using CVS 181

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.


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.

This discussion has been archived. No new comments can be posted.

Pragmatic Version Control Using CVS

Comments Filter:
  • by pcraven ( 191172 ) <paul.cravenfamily@com> on Tuesday December 30, 2003 @01:50PM (#7836556) Homepage
    For me, I thought Code Complete [amazon.com] was the book for learning good coding.

    On another note, does anyone else want to scream every time someone says 'best practice'?
  • by Frymaster ( 171343 ) on Tuesday December 30, 2003 @01:56PM (#7836635) Homepage Journal
    look at this:

    cvs checkout -r mytag repository

    cvs log -rmytag -d 'yyy-mm-dd'

    two -r switches but... the first one has a space before the tag, the second one doesn't. when you look at the cederquist doco online the html really doesn't make this clear.

    if this book addresses this one quirk it's worth a hundred bucks.

  • by Anonymous Coward on Tuesday December 30, 2003 @02:20PM (#7836929)
    I'm using Netbeans on Linux. The other developers are using JBuilder on Windows. I can set up a CVS server and everyone is happy. Arch won't do that yet (righ?).

    I can't really dump CVS until there is support for the major IDEs (Including EMACS!).

    Interestingly, Subversion support for Eclipse and Netbeans is available.

    -- ac at work

  • Re:CVS cons? (Score:1, Insightful)

    by Anonymous Coward on Tuesday December 30, 2003 @02:42PM (#7837147)
    I'm a full-time admin/developer for a commercial website and I began storing 10K+ lines of PHP scripts in CVS about 2 months ago. I have two words for you: BUILD SCRIPT.

    My script accepts flags for checkout, update, or export. Use checkout for a fresh copy if you think you might make some edits that you'll want to commit. Use update to refresh an older checkout. Use export to publish pure code without CVS metadata (you won't be able to commit any edits later, though). The build script clears out (rm -rf) the build directory for checkout/export. The last step is to set the proper file permissions.

    It's a very safe, content feeling you get when you know that your entire codebase can be wiped out (on the webserver) and at the push of a button you can rebuild it from a remote repository.

    I was intimidated by CVS at first, but now I can't live/work/play without it.
  • Re:CVS cons? (Score:1, Insightful)

    by Anonymous Coward on Tuesday December 30, 2003 @03:00PM (#7837379)
    Until you've rescued an inexplicably broken build with a quick 'cvs diff' its hard to understand how useful cvs can be for lone developers.
  • by HopeOS ( 74340 ) on Tuesday December 30, 2003 @03:09PM (#7837459)
    I develop dozens of projects concurrently. Keeping all the development details straight can be difficult, particular when reapproaching a project that has been untouched for several months. The ability to back out non-obvious design mistakes, start speculative development branches, and distribute projects across multiple machines, depending on where I am at any point in time has made single version control a necessity for me.

    Starting a project in CVS is simple.

    Create a directory. Maybe add a descriptive text file or two. Run cvs import from within the directory. You'll then need to do a checkout, and you're ready to begin adding makefiles, source code, autoconf delights/madness. For what it's worth, I always rename the original directory before the checkout in case CVS has a glitch. Older CVS balked at overwriting the files; maybe that's still the case.

    The last reason that I use source control even for projects that I am the sole developer is that I have on occassion, deleted critical files by mistake, and had to reimplement entire classes/modules under duress. It's a rare event, but with source control, I'm less stressed over the possibility of screwing up.

  • by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Tuesday December 30, 2003 @03:31PM (#7837760)
    I'll grant that Arch takes a while to grok -- I spent at least a few days wrapping my mind around it. Actually following along with the examples in the tutorial helps.

    WRT your "unfinished" impression: The code itself is very clean, well-polished, readable, and robust. My only qualm is with the error-handling; there are lots and lots of sanity checks throughout, but the error messages aren't always as useful as they could be (asking for a revision that doesn't exist might give something like "File not found", or even more opaque, rather than "that revision does not exist"). Bugs that cause such things to happen without involvement of user error are extremely uncommon.

    With regard to speed, I'm not sure if you'recomparing SVN to CVS or Arch; if the latter, be sure you're comparing against tla 1.1 or later with a revision library enabled. (Even more optimizations are on their way -- Chris Mason of SuSe has proposed a patch which brings the time to replay 100 changesets down to about 4 seconds in optimal conditions; some cleaned-up variant may well make it into tla 1.2 or 1.3).
  • by Fnkmaster ( 89084 ) * on Tuesday December 30, 2003 @03:33PM (#7837780)
    That rant seems to focus on the wrong things. Subversion should probably be more stable than it is for a 3 year old project, and I think they do some stupid things - for example, binaries should be available, more emphasis on stable releases, not just "oh, use your own subversion to check out the latest subversion sources..." please... we don't all want to be fucking SCM system developers, we just want to use it.

    But knocking Subversion because of the version numbering they use is dumb. Knocking Subversion because the system can integrate with Apache2 is dumb. Claiming that the features Subversion adds over CVS are trivial is crazy, and claiming every other SCM/version control system has them is just factually wrong. I agree that a good, modern SCM system has atomic commits, but if it was so damned simple, show me all the other systems that have implemented it that don't cost many hundreds to many thousands of dollars per seat license.

    And there are graphical tools for Subversion, though I haven't really played with them much - rapidSVN looks like the rough equivalent of a cross-platform version of WinCVS, and tortoiseSVN is a rather interesting concept, integrating in as a Windows Explorer extension.

  • by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Tuesday December 30, 2003 @03:54PM (#7838029)

    Re versioning directory structures: If I rename the directory "a" to be called "b", and do a commit, I want people who do an update to suddenly have "a" renamed to "b" -- with all their local changes still intact. Subversion does it, Arch does it, CVS won't.

    With atomic commits: I change 3 files. I want do a single commit that makes these 3 files part of one atomic change. If someone does an update and gets one of these, I want them to get all of them. (Say they're a change to a method description in a header, a change to the C file implementing that method, and a change to another file calling it -- if someone does an update and only gets one of the 3 they always have a broken tree; they should have all or none). CVS won't do that; Subversion will, Arch will.

    See my other post [slashdot.org] for a bit more on why modern revision control systems are more useful.
  • Re:CVS cons? (Score:2, Insightful)

    by foandd ( 629361 ) on Tuesday December 30, 2003 @04:32PM (#7838373)
    I certainly took no offense, and I hope you take no offense when I say I can't believe anyone would pass up a contract just because of a lack of source control...

    I think you need to look at his comments from the standpoint of someone who has gotten used to using source/version control. It may be hard to believe if you never have, but it really can make that much difference.

    I used to do things the way you do, and tried CVS mostly out of curiosity. I couldn't go back. There are just too many benefits, most of which are things I hadn't thought of before using it.

    If things work well for you, no sense in rocking the boat I suppose, but don't blithely assume using CVS would have no benefits; you're wrong. They may not be compelling enough for you to change, but they most assuredly exist.

  • by axxackall ( 579006 ) on Tuesday December 30, 2003 @09:18PM (#7841360) Homepage Journal
    Bitkeeper is not free. Subversion is not really ready. But why people ignore Arch and Aegis then?

    Aegis is around for about 10 years - for that time people could already recognize it's great features, design and implementation. Why didn't they do?

    I am suspicios that most of people tend to prefer more primitive solutions by the same reasons as they stick to Windows. They can quickly start, but they don't really care about upcoming problems.

    When I think about huge popularity of Windows and CVS I begin to disappoint in the humankind.

"The pathology is to want control, not that you ever get it, because of course you never do." -- Gregory Bateson