Slashdot Mirror
Pragmatic Version Control Using CVS
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 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.
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!
Subversion still seems to have a few serious issues including rename is not atomic.
/etc/passwd file?
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
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?
"Can of worms? The can is open... the worms are everywhere."
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?
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.
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
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.
-- The world is watching America, and America is watching TV.
Yes, but CVS is unfortunately "good enough" (and just barely).. all those other systems have their own shortcomings:
.. 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.
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.