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.
This site has more reviews for this book.
For me, I thought Code Complete was the book for learning good coding.
On another note, does anyone else want to scream every time someone says 'best practice'?
Time to bury CVS, not to praise it.
Check out Arch.
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.
2 1337 4 u!
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 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!
Yep. I started using it about a month ago. Within three days I was so enamoured of it that I switched all my projects to it. Anyone who has used CVS should be able to switch almost without retraining. And the best thing of all is that the documentation (a downloadable book) is thorough, well-written, up-to-date, and full of useful examples. This project should win some sort of prize; it deserves it.
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
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:
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
Open Source Development with CVS by Karl Fogel is a great online CVS manual and reference. I use it all the time.
JP
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.
Look up commitinfo in the CVS manual. It does both of these things.
I. Free or nearly free--includes: CVS & SubVersion.
II. Under $1000 per seat--includes: AccuRev & Continuus CM.
III. More $$$ than you can possibly imagine--includes: ClearCase & StarTeam.
To cut it short, we eventually went with AccuRev, due mostly to environmental and budgeting restrictions. It's an unobtrusive, often maddingly slow, Java-based product, which happily fits most of our needs.
There's a huge field of versioning products out there, most of which can only be found on poorly documented company websites, many without demo's. And each of them promises to be the last word in SCM, but with little to no comparison between vendors. (Oh sure, product FooSCM includes LifeCycle Management, but the definition & amount of "Lifecycle" varies greatly from one product to the next!)
Caveat emptor!
Stuff that matters: circuitbreakers, vacuum-cleaners coffee makers, calculators generators, matching salt+pepper shakers
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?
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.
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
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
Actually, subversion went beta before Christmas.
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.
Less is more !