Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Programming Books Media Book Reviews IT Technology

Pragmatic Version Control Using CVS 181

Posted by timothy
from the means-ends-analysis dept.
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.

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

Pragmatic Version Control Using CVS

Comments Filter:
  • by pcraven (191172) <paul AT cravenfamily DOT com> on Tuesday December 30, 2003 @12:59PM (#7836681) Homepage
    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.
  • CVS cons? (Score:3, Interesting)

    by jason.hall (640247) on Tuesday December 30, 2003 @01:03PM (#7836722)
    I've always found CVS to be more trouble than it's worth. I do small-time development with Mac OS X (previously Project Builder, now Xcode) and like the *idea* behind CVS. But the articles/tutorials I've read are either how to install (which I have) and just go over the commands, or they're geared toward the expert. I haven't found much info on conceptual/fundmental questions, like on integrating with IDEs, for instance "do I check the entire development tree into CVS, or just the text files?" If it's just the text files, that seems like a lot of work. "How do I put my web site HTML files into a repository and still have the web server still be able to access it?" Overview stuff like that.

    My current way of version control is the old way of just zipping up each release!
  • by Fnkmaster (89084) * on Tuesday December 30, 2003 @01:11PM (#7836815)
    CVS is good. But not great. Subversion [tigris.org] has the potential to be great - atomic commits, versioning of directories, moving files easily, cheap branching. All those things that ever made you want to smack your computer upside the head when you were using CVS because they were so obviously the WRONG way to do version control.


    Unfortunately, subversion seems to be always _almost_ stable enough for real use. Maybe this has changed recently (I've just played with it, I still use CVS for real work). I haven't really checked out GNU Arch [gnu.org] - it seems to claim to support changesets (groups of changes), and thus I presume atomic commits, better/faster branching and merging and so on - the other good stuff that CVS is lacking. My guess is that Arch is even less mature than Subversion though, since it appears to have not been around as long.


    Anyone else know of any other good alternatives that are more mature?

  • by Anonymous Coward on Tuesday December 30, 2003 @01:14PM (#7836860)
    Subversion still seems to have a few serious issues including rename is not atomic.

    Also, CVS, Subversion and Arch all require unique UNIX user accounts to access their repository - this sucks from an administrative and security point of view. I just want contributers to read from and commit to the repo - not have UNIX access of any kind. Is there a free RCS that just runs as a server and does not require monkeying around with the box's /etc/passwd file?
  • by stefanlasiewski (63134) * <slashdot@stef a n c o . com> on Tuesday December 30, 2003 @01:20PM (#7836924) Homepage Journal
    Really? Could you please provide some reasons why Arch is better then CVS instead of just pasting a link?

    Are the authors of the book praising CVS? Or are they just using it as an example "given that CVS is free and widely used"?

    How the heck did this get a +4 Informative?

  • by BlueFall (141123) on Tuesday December 30, 2003 @01:42PM (#7837159)
    Does Subversion really handle the repeated merge problem now? I have heard that Arch does do this and I don't really know about bitkeeper. I'd say that this is my personal biggest beef with CVS (aside from its ridiculously inefficient storage scheme).

    Last time I checked, repeated merge was a post-1.0 issue, but for me, it's the only reason not to move to Subversion.
  • by Anonymous Coward on Tuesday December 30, 2003 @01:43PM (#7837162)
    All that may be true, but something about developing your own filesystem (kernel integration) just so you can back out of mistakes rubs me the wrong way. Why not integrate into pre-established file systems that already do snapshoting? Such as Network Appliance, which already does it better and faster. Any time you need to buy disk storage and a separate server to run a revision control system, you end up painting yourself into a corner.
  • by cduffy (652) <charles+slashdot@dyfis.net> on Tuesday December 30, 2003 @01:52PM (#7837274)
    Does Subversion really handle the repeated merge problem now?

    Hmm -- I don't know for sure on Subversion; perhaps someone else here will comment. I'm positive that Arch does (it's what I use personally), and pretty sure that BitKeeper does.

    Just curious -- any particular reason you're not considering Arch?
  • vendor branches???? (Score:1, Interesting)

    by Anonymous Coward on Tuesday December 30, 2003 @02:23PM (#7837634)
    So.. does this book explain vendor branches *well*?

    Does it explain why files stay on the vendor branch until you change them? (Which means if you change a couple files, they are on your main line, but the rest stay on the vendor branch).

    That really bugs me (i.e., shouldn't the vendor branch be tagged with only vendor's version numbers, and your main line be only tagged with YOUR tags, instead of mixed on both branches?)

    I found out that "cvs admin -b" will move the vendor code to the main line, so I always run that command after importing vendor branches. But it really doesn't make sense.

    It's much more logical to do vendor branching in Subversion (even though you are technically doing them "by hand", like all tagging and branching in svn).

    Anybody know what I'm talking about, or is this like "super-advanced CVS for anal pricks"? Maybe. :-)

    Anyway I hope this book is good. I found the O'Reilly book to be awful. I love their Ruby book.
  • Re:CVS cons? (Score:4, Interesting)

    by rleibman (622895) on Tuesday December 30, 2003 @02:31PM (#7837763) Homepage
    No offense, but I hope I'm never in a project with you.
    Programming (at any level, small OR large) without source control is like playing in the high trapeze without a net, yeah, you can do it, and if you're really good you'll get away with it for a while, but when you miss you'll be sorry.
    Source control gives you a backup of your work, a storyline of what you've changed add to that the advantages of such a system when working with more people and I really can't imagine not having a source control system.
    As a consultant, it is the first question I asked before taking on a project: what do you use for source control. I run away if they don't have one and are not willing to let me install one.
  • by cduffy (652) <charles+slashdot@dyfis.net> on Tuesday December 30, 2003 @02:38PM (#7837854)
    My guess is that Arch is even less mature than Subversion though, since it appears to have not been around as long.

    Actually, in practice, I've found Arch to be not only more featureful than Subversion, but much more robust as well.

    Tom Lord (Arch's author) has written a few screeds with his interpretation of where the Subversion design and development process went wrong (to take so many man-hours to develop a product which, in his view, has severe design flaws); his arguments there are likely to be much better than any I could make here.
  • by HopeOS (74340) on Tuesday December 30, 2003 @02:44PM (#7837915)
    There are two environment variables to be aware of, CVSROOT, and CVS_RSH. Setting CVSROOT isn't necessary, but it simplifies the cvs command line a little bit for first time users. I keep these variables in my .profile, but often as not, I use the cvs -d parameter to specify the exact repository. Once checked out, the project will remember where it came from. I use SSH for remote repositories, so the CVS_RSH environment variable is always set.
    [~me]$ export CVSROOT=/path/to/local/cvs
    or
    [~me]$ export CVS_RSH=ssh
    [~me]$ export CVSROOT=:ext:me@myserver:/path/to/remote/cvs

    Generally, you may wish to start with a simple project and check it in before beginning your work in earnest. The fewer files the better, and if you've already run configure and have hundreds of non-source build files in the directory already, it can be time consuming to remove them, despite helpful make targets. I try to start with as few files as possible, and add all my source files explicitly.
    [~me]$ mkdir foo; cd foo
    [foo]$ touch ChangeLog
    [foo]$ cvs import foo me initial
    [foo]$ cd ..; rm foo
    From here, one merely needs to checkout the project, add, and commit source files.
    [~me]$ cvs checkout foo
    [~me]$ cd foo
    [foo]$ vi Makefile foo.c
    [foo]$ cvs add Makefile foo.c
    [foo]$ cvs commit
    Obviously, a good bit of the first part could be scripted... I don't bother since I find project setup somewhat zen anyway. I enjoy the ceremony of it, and it's not a daily task anyway.

    -Hope
  • by pHDNgell (410691) on Tuesday December 30, 2003 @04:58PM (#7839536)
    I can't really dump CVS until there is support for the major IDEs (Including EMACS!).

    Apparently one of the xemacs developers uses arch, and I've read about various emacs arch integrations.

    Personally, I don't really see the point of an IDE in general (and I get plenty done). The most important thing to me is keeping my source safe. Having replicates, knowing that changesets are *not* ever modified, etc...gets me there. Toolkit integration is secondary.

    That said, I do have vim adding arch-tags to code when I add it. I can just sit around making changes to code and then then create a commit message and check it all in when I'm done, knowing any file I added, deleted, or modified will be picked up transparently.

    I also use xcode for some projects, and get the same effects.
  • by Anonymous Coward on Wednesday December 31, 2003 @12:59AM (#7843112)
    Yes, but CVS is unfortunately "good enough" (and just barely).. all those other systems have their own shortcomings:

    subversion: grotesquely bloated opaque "versioned filesystem" built on top of BerkelyDB... not really based on changesets, it can't remember what you've merged.. has a nice CVS-like interface though. I personally believe that versioned filesystem business will become a huge albatross once they run into the practical problems of computing and storing deltas *efficiently*, and handling the changeset concept properly.

    arch: confusing and non-intuitive interface .. many things take multiple intermediate steps instead of one .. versions and revisions have an odd syntax with "--" in between the components. Directories/URLs with "{}" in the name are problematic. Wonderfully pragmatic storage mechanism though, the best of "hackable" CVS repositories and atomic databases.

    bitkeeper: proprietary, issues on Linux kernel list leave a bad taste in my mouth (I don't care about "programmers paying their mortgage", I care about getting my work done). Can eat up RAM.

    perforce: proprietary, though actually I kindof like this one, but too expensive for me.

    I'm waiting for the perfect version control system, none of these are it. So with a heavy heart I continue to use CVS. For my purposes it does the job. I'd love to see a CVS-like interface on Arch though, or at least a *simpler* interface. The help screen is 182 lines long!! for CVS it's like 40.

Hold on to the root.

Working...