Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
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 More

Pragmatic Version Control Using CVS

Comments Filter:

  • more reviews (Score:4, Informative)

    by Anonymous Coward on Tuesday December 30, 2003 @12:48PM (#7836534)
    This site [verygeekybooks.com] has more reviews for this book.

  • Which book was a watershed event? (Score:5, Insightful)

    by pcraven ( 191172 ) <paul&cravenfamily,com> on Tuesday December 30, 2003 @12: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'?
    • Oh. My. Dog.
      You recommended a book by a MICROSOFT EMPLOYEE? Heresy!
      (HHOS.)

      Actually, McConnell has a whole slew of good books out, Code Complete being only one of them. He even has a book on rapid development [amazon.com], that is also mighty good.
    • I concur with this. I highly recommend Code Complete for developers of all experience levels. It provides a nice basis for best practices, with explanations as to why the recommendations are made etc. Very useful information in there! I've had countless coworkers and developer acquaintances read it.
    • I just finished reading it last week. You would think that a ten to twelve year old book would seem crusty and outdated, but it's by far the most relevant book I've read in the last couple of years.

      Actually, there were a few points where it seemed like he really should have thrown in some discussion of Java, and I slapped myself when I remembered that it predates the language.

      "Best practices" isn't too bad a concept, though it tends to get abused a lot. "Best of breed" is the phrase that really make

  • GNU Arch is better than CVS (Score:2, Informative)

    by Anonymous Coward
    Time to bury CVS, not to praise it.

    Check out Arch. [gnu.org]

    • I wonder what source control they are using. :)
    • 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?

      • Re:GNU Arch is better than CVS (Score:1, Informative)

        by Anonymous Coward
        Why choose Arch [gnuarch.org]
        Arch Comparisons with other VC systems [gnuarch.org]
        Arch Wiki [gnuarch.org]

    • Wait for IDE support, please... (Score:4, Insightful)

      by Anonymous Coward on Tuesday December 30, 2003 @01: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

      • 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
    • I've tried to read the Arch manual three times now and given up every time. Maybe its better for large projects, I dont know. The website and everything about just gave me this unprofessional, unfinished feel to it.

      Subversion [tigris.org] looks a lot nicer than Arch. svn just tries to be a "better cvs" and fixes a load of the nasty things about CVS. Its a lot faster too, and theres a plugin which lets you use it in Eclipse. Plus it has some pretty cool features like the apache plugin which lets you check out over ht

      • Re:GNU Arch is better than CVS (Score:5, Insightful)

        by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Tuesday December 30, 2003 @02: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).
        • 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

          That's nothing, SVN and Arch only go up to 9, while CVS goes all the way up to 11!

  • what i hate about cvs (Score:5, Insightful)

    by Frymaster ( 171343 ) on Tuesday December 30, 2003 @12: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.

    • The space between the option and the argument is always optional.
    • CVS has appeared as a set of Perl (!) scripts around RCS. It was never designed like a system should be - it's just appeared, or happened. And of course, it's original language (Perl, later it was re-written into C) did not add anything clear to it.

      I am not trolling - I was reading it in several places as a historical comment of original CVS developers. Someone with better mmemory (or a longer bookmark list) may drop even URL here.

    • cvs -H checkout
      cvs -H log
      cvs -H

      The cvs command has two options sets, the first for cvs (like -q for quiet) and the rest per command (checkout, log, etc). Yes, the space thing is a quirk that shouldn't be, but the -H listings reliably show which it should be for a particular command.

  • But does it have a GUI (Score:3, Funny)

    by Anonymous Coward on Tuesday December 30, 2003 @12:57PM (#7836643)
    Unless the source control software has a complicated GUI from which you can cut and paste stuff into powerpoint, and makes checking in a file, a longer process than software development, our bosses won't go for it

  • CVS good, ClearCase bad (Score:5, Interesting)

    by pcraven ( 191172 ) <paul&cravenfamily,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.
    • Seems like a lot of the clearcase features seem to be targetted towards extremely large projects involving 100s of people in a controlled environment (such as a corporationa as opposed to open source development). Using Clearcase in smaller projects involving fewer people seems way more trouble than it is worth. Clearcase sucks ass at least for such projects.
      • If you're using Clearcase, you need a specialized admin for it. This puts it in the large organization category. Maybe you could get away with installing it without knowing much about it, and just using its basic check-in/check-out features, but then you might as well save the money and use RCS. CVS is a lot easier for the average developer to just pick up and run with, and learn about as they go. 90% of projects do not use what CVS has to offer (scripting to check commits and log messages, vendor branches
    • 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

      • Anyone use Merant PVCS? Lacks some basic features but simple and quick.
        • Anyone use Merant PVCS?

          I HATE PVCS WITH A PASSION!

          Does that answer your question?

          To qualify that statement, PVCS does not help (in any way shape or form) in helping you track files that have changed. Instead, you have to spend your time carefully managing your locks or tracking your files in a text file. The former is not a good method, as invariably, someone else needs the same file. Even worse, is that when you do get your lock back, PVCS will not ask about merging, it will simply f**k up the file for
      • ummmm - you can version directory structures under CVS - as well as any file types you care to think of (binary).

        Additionally, define what you mean by 'atomic commit'. If that means you can commit the changes of just one file in the set - then CVS handles that too.

        I will have to agree - moving files is a pain in CVS. However, such a major change to your directory structures would probably warrant a new top level anyway...

        • Re:CVS good, ClearCase bad (Score:5, Insightful)

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

          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 good, ClearCase bad (Score:5, Interesting)

        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.
      • I haven't really checked out GNU Arch - 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.

        Try arch, it's amazing. I've thrown away CVS at my installation in favor of arch. It works quite a bit better than anything else I've used (which is pretty much RCS, C
        • I'm trying to find information on building/using Arch for Win32. I see some references to using it under Cygwin - less than ideal, IMHO. Sure, it depends on patch, tar and diff, but I have MinGW builds of these and they are readily available for Win32. Maybe I'll futz around and see if it's possible.
          • I'm trying to find information on building/using Arch for Win32. I see some references to using it under Cygwin - less than ideal, IMHO. Sure, it depends on patch, tar and diff, but I have MinGW builds of these and they are readily available for Win32. Maybe I'll futz around and see if it's possible.

            Sorry, I don't do windows, so I can't offer much help there.

            It's really just that much different from other programming environments, which makes it hard for open source projects for open source systems to c
          • You just hit on a weak point there -- Cygwin won't run Arch correctly on complex repositories until some fixes to support long filenames (by using the Win32 unicode file management API) are in.

            Such a patch has already been written, but its contribution is being held up by legal issues (the author did it on company time, and he needs to jump through a bunch of hoops before his employer will agree to transfer copyright).

            Presumably Tom could work on writing support for the filesystem abstraction layer and su
      • Subversion uses webdav. And for some admins that's a too big security risk.

    • Re:CVS good, ClearCase bad (Score:4, Informative)

      by Anonymous Coward on Tuesday December 30, 2003 @01:15PM (#7836866)
      Informative? Makea few bold assertions without proof or understanding and its informative?

      I have supported development using CVS, SCCS, ClearCase, Kintana and BitKeeper. Each system has its advantages and disadvantages. For ClearCase, the biggest disadvantage is you have to read the manual.

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

      If I tune my mustand to run like crap, it will. Don't blame a tool if you haven't RTFM.

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

      Bold assertion, care to provide even the slightest amount of example, or dare I say proof? How about a plan for using CVS across 500 developers in 8 sites, on 5 time zones. Ohh, and we are a worldwide company, so all developers need access to all code.

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

      True. Thanks for providing context with a claim.

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

      Probably another RTFM. ClearCase has many powerful tools, but you have to learn how to use them. This in itself is a downfall as the quality of available software engineers continues to fall.

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

      Why? ....

      "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."

      Your wrong, but I don't have time to cut an paste the manual over. You really should trying reading it sometime.

      "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."

      I think your kinda sorta talking about a Snapshot view. Read the manual, pick up the nomenclature. It takes me 3 seconds to pick up all the changes in need in my dynamic....

      "CVS is free."

      True.

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

      I call bullshit. Its clear(har har) that you have never supported Software configuration management. CVS doesnt require training if all of you engineers already understand CVS. I expect the same to go for ClearCase...

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

      It has flexibility, which last time I looked increases strength. Learn what you need and ignore the rest.

      • Re:CVS good, ClearCase bad (Score:1, Interesting)

        by Anonymous Coward
        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.

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

      Checking out a repository with a server-side cachrev is, in Arch, as fast as downloading and unpacking a tarball of the project over $CHOSEN_TRANSPORT (say, http). Creating a working directory of a repository with a client-side revision library is, with all the optimizations turned on, as fast as creating a hardlink tree shadowing the revision library's tree. (Of course, this needs to be done with your editor set to bre

    • CVS is a source control tool. ClearCase is a configuration management tool. There is a whole world of difference, which is why ClearCase sucks if you're using it purely for source control.

  • 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!

    • Source control really shines when you work with multiple people.

      If you are working alone, then its worth it if you want to track down the date and exact changes you made.
      • If you are working alone, then its worth it if you want to track down the date and exact changes you made.

        Some IDEs (e.g. JBuilder) have this built-in, so you don't need CVS et al for it.

    • Re:CVS cons? (Score:3, Informative)

      by Violet Null ( 452694 )
      Last item first:

      My current way of version control is the old way of just zipping up each release!

      If it's just you working on this...well, that's fine. And it probably is the easiest. There's little-to-no reason to use CVS if it's just you.

      But, otherwise:

      I haven't found much info on conceptual/fundmental questions, like on integrating with IDEs

      Depends on the IDE. Most plugins for Windows or *nix shell out to the command line CVS, and process its output. But, I'm not familiar with Mac IDEs at all

      • But, again, CVS use is only compelling if you have more than one person working on the project at the same time.

        Unless, as a programmer, one suffers from split and competing personalities. Always looking over your own shoulder, second-guessing the changes made to "your" own code...

        Even for a single developer, and even in the context of webwork, cvs (or arch, subversion, etc.) is a relatively painless way to track modifications over time without heavy accumulation of redundancy (=unaltered clutter)

      • Pros for single user version control (Score:4, Insightful)

        by HopeOS ( 74340 ) on Tuesday December 30, 2003 @02: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.

        -Hope

        • Example CVS project starting point (Score:4, Interesting)

          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
      • But, again, CVS use is only compelling if you have more than one person working on the project at the same time.

        Right. Because you've never implemented a new feature only to find that it broke something you thought was totally unrelated. Version control is great for "It worked on Monday" kinds of situations where you want to see what your code looked like. Most of my projects are just me and I won't work without my SVN server.

      • > But, again, CVS use is only compelling if you have more than one person working on the project at the same time.

        Ummm, I would have to disagree. I used CVS for my labs in a cs class, it was great.
        Never had to worry about making back-ups or screwing something up and not being able to go back to the working original.

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

      by Anonymous Coward
      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 -r

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

      by Anonymous Coward
      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.

    • 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.
      • No offense, but I hope I'm never in a project with you
        Don't worry, I'm a single-man operation. :)

        I obviously don't have the CVS mindset. It just seems like a "geeky" gadget (being a geek myself, mind you, and there's nothing wrong with gadgets). About 90% of your post would be applicable if I didn't keep backups, but like I said I do - I just zip up each release. The point about having a storyline is satisfied by my changelog. In years of development for both large and small projects, I've only bee

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

          by foandd ( 629361 )
          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, mos

        • 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.

          Maybe I exagerated, not *just* because of a lack of source control, but that is one question that I do ask and I find it indicative of the maturity of the environment I'll be working with.

          If the place is immature, chaotic and unwilling to learn and apply good engineering practices (which in part is why my expertise is valuable) then I'm not sur
    • Wow! you really need to buy and read this book--or you are not a *software* developer, so it just does not matter.
  • I'm crazy about Andy and Dave's Pragmatic Programmer and Programming Ruby books, so naturally I had this book as well as Pragmatic Unit Testing on my Christmas list.

    As someone whose been desparately trying to get a grasp on some advanced CVS concepts lately, especially vendor tags and tracking of third party sources, I'm a little disappointed at the slow start the book gets off to; it feels just a bit belabored reading another introdution to the basics, but I'm glad to hear there's good stuff further on.

  • svn (Score:1, Informative)

    by XtAt ( 31970 ) *
    who uses cvs anymore? [tigris.org] *giggle*

    By the way, backports.org has a wonderful woody backport of subversion.
    • Anyone who don't want to use a cvs system, which is not even in beta yet.

      But I am waiting for subversion to finish their version 1, so I can kill -9 cvs forever

      • But I am waiting for subversion to finish their version 1, so I can kill -9 cvs forever

        Try tla (arch)'s 1.1. It's far easier to set up and fairly well along (as far as I can tell, it does more, and does so more reliably and flexibly). Or if you want, try the 1.2 betas and get gpg support.

    • Re:svn (Score:2)

      by aled ( 228417 )
      One feature that CVS has, or better say that WinCVS has is the graph of versions. I love that graph, it let's me see the revision tree at a glance and diff between any revisions just selecting them. That's a feature that you won't be seeing in Subversion because the info is not avalaible to the client. As in Subversion tags/branchs are not first class citizens I don't know it ever will be implemented.
      At least that was the status the last time I checked some months ago and no release from that did suggested

  • slashes (Score:4, Funny)

    by sfraggle ( 212671 ) on Tuesday December 30, 2003 @01:08PM (#7836781) Homepage
    I give it '10 out of 10 slashes.'
    Books are hard to read if you slash them to bits!

  • Shoehorning CVS to work with good dev practices... (Score:5, Informative)

    by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Tuesday December 30, 2003 @01:17PM (#7836891)
    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
    • 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.
      • 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?

    • Re:Shoehorning CVS to work with good dev practices (Score:4, Informative)

      by jrumney ( 197329 ) on Tuesday December 30, 2003 @01:43PM (#7837164)
      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.

      Look up commitinfo in the CVS manual. It does both of these things.

      • I distinctly recall commitinfo not being useful for this in actual practice. It was a while ago, so I'm not sure why -- perhaps it was running on the client rather than the server? (Of course, what we *really* need is a 3rd machine set up as the canonical dev environment running the tests, neither the client nor the revision control server -- something which tla-pqm makes trivial).

        I can ask the IT lead why that was, if you're really curious; his memory's better than mine.
    • Arch avoids the whole issue by never rewriting or removing files which have been added to the repository

      I don't think this can be emphasized enough. The most important thing a revision control system can do for me is guarantee the safety of my code (as it's my work product and the most valuable thing I've got). Knowing that the history of my project is accurate because it is never modified (by the arch tools, anyway) is very important to me.

    • 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

    • Thanks for the detailed description, in particular for your clear description for what you might want to do with a distributed version control... I've read a number of pro and anti bitkeeper flames, but none of them have made that clear.
  • Bitkeeper? I've seen a few good OSS projects use this and read some good things about it. Anyone, anyone? Bueller??

  • Online CVS reference (Score:5, Informative)

    by jpkunst ( 612360 ) on Tuesday December 30, 2003 @01:25PM (#7836977)

    Open Source Development with CVS [red-bean.com] by Karl Fogel is a great online CVS manual and reference. I use it all the time.

    JP

  • I've only met one person who used CVS and he used it to version control his mbox files! Obviously, CVS can be used on any text file but is it really useful for non-programmers?

  • vendor branches???? (Score:1, Interesting)

    by Anonymous Coward
    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 alway
  • Its pretty amazing that no one has mentioned TortoiseCVS [tortoisecvs.org] yet. If you are using CVS and are stuck on the windows platform, then Tortoise CVS is a god send.
  • Not very pragmatic if I can't buy it at Amazon. I don't live in the US and I don't have a credit card.

Slashdot Top Deals

Nothing ever becomes real till it is experienced -- even a proverb is no proverb to you till your life has illustrated it. -- John Keats

Close