Pragmatic Version Control Using CVS 181
| 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.
CVS good, ClearCase bad (Score:5, Interesting)
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)
My current way of version control is the old way of just zipping up each release!
Re:CVS good, ClearCase bad (Score:3, Interesting)
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?
Subversion stability? (Score:1, Interesting)
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
Re:GNU Arch is better than CVS (Score:2, Interesting)
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:Shoehorning CVS to work with good dev practices (Score:3, Interesting)
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.
Re:CVS good, ClearCase bad (Score:1, Interesting)
Re:Shoehorning CVS to work with good dev practices (Score:3, Interesting)
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)
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)
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.
Re:CVS good, ClearCase bad (Score:5, Interesting)
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.
Example CVS project starting point (Score:4, Interesting)
or
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.
From here, one merely needs to checkout the project, add, and commit source files.
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
Re:Wait for IDE support, please... (Score:3, Interesting)
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.
Re:Shoehorning CVS to work with good dev practices (Score:1, Interesting)
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
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.