Slashdot Mirror
Open Source Development with CVS
The Scoop Free software, the theory goes, is in a constant state of release. Instead of working in secret for years to produce a Grand Unified Model of Everything, then unleashing it on an unsuspecting world to the accompaniment of television commercials and full-page ads in trade magazines, development occurs in public view. That's aided, in no small part, by the convenience of CVS. So argues Karl Fogel in his introduction to Open Source Development with CVS. In that case, why not try it yourself?
Interspersed between CVS How-To chapters are Developer How-To chapters. For example, chapter 3 describes the author's theories on the entire Open Source process. That includes such common-sense advice as "Release something useful" and "Release something usable." There're plenty of examples to back up these ideas, drawn from the examples of large and popular open source projects.
What's to Like? CVS-specific chapters build on each other. Though 95% of the commands the average developer will ever use are covered in chapter two, the increasingly specific information just may come in handy someday. Though there's a price to pay for flexibility, the increased power it brings is worth it. If you've followed the examples and done some testing of your own, you'll have earned the title 'CVS Guru' by the end of chapter six.Fogel's development essays take the pragmatic approach. Rather than preaching the One True Way to Do It, he analyzes several successful projects (Apache, the Linux kernel, and CVS itself being among the most prominent) and attempts to draw general principles from their histories. His overall philosophy seems to be "manage a few things well and strictly, and let your project evolve." With a good framework in place (both in your code and for your project administration), things will work smoothly and you'll be more likely to reap the benefits of the free software model.
Chapter eight gives troubleshooting tips. Fogel walks through the most common errors he's seen, doling out explanations and solutions with abandon. Chapter nine is a good reference, neatly summarizing CVS commands and files. Having completed the rest of the book -- and understanding the concepts, this section has the exact syntax at your fingertips.
What's to Consider? Though a complete reference on its own, occasionally the author defers discussion of some subjects in favor of referring to the Cederqvist manual accompanying a CVS source distribution. To be fair, these are often highly technical minutiae, but at 316 pages there is space for an expanded explanation of topics such as the RCS roots of CVS (knowing the source of CVS can help one to understand why some things are the way they are). Thankfully, there's information provided about the official FAQ and mailing lists where such data can be found. The Summary Beyond a comprehensive guide to using and administering CVS, Karl Fogel has written an easy-to-read guide on successful Open Source development. His practical focus and laid-back approach should prove workable for everything from pet projects to large undertakings. The author and Coriolis, the publisher, have also made chapters 2, 4, 6, 8, 9, and 10 available online at http://cvsbook.red-bean.com, under the GPL. Table of ContentsPurchase this book at ThinkGeek.
- Why Open Source Development and CVS Go Together
- An Overview of CVS
- The Open Source Process
- CVS Repository Administration
- Designing for Decentralized Development
- Advanced CVS
- Building, Testing, and Releasing
- Tips and Troubleshooting
- Complete CVS Reference
- Third-Party Tools That Work With CVS
- CVS Maintenance and Development Today
- GNU General Public License
Clearcase is pretty good and Visual Source Safe works well on Win32. I think CVS is superior because it is more cross platform and *flexible* about what you can do with it. I like being able to migrate development over various platforms because you never know when Win32 will suddenly cease to be viable or Linux will pale next to Solaris for some high-performance server side code [hey, it could happen]...
My employer purchased the book about 6 months ago on my recommendation. The FAQ and Cederqvist are great, but I thought this was the best way to introduce the office to CVS.
As the review said, when you're asking the technical questions, the answers can be found. I don't think that Fogel was trying to replace Cederqvist on that front.
Um, no.
Karl Fogel and Coriolis, the copyright holders, can do whatever they want with the material that they hold the copyright to.
Another author using those chapters in a derived work would have to release the derived work under the GPL, or obtain a separate license from the copyright holder(s).
FWIW, I went to school with Karl. Never knew him, but it's neat to see that he's written a book. Makes me feel inadequate, too.
pooptruck
BOFH, My model for being a sysadmin :)
I own this book, and I found it interesting that the chapters that were made available on the net were the chapters concerning technical matters, whereas the chapters I found most interesting, concerning the social aspects of CVS and Open Source projects are only available in the printed version.
This makes a lot of sense, from the authors perspective (and from ours as users of open source), since technical documentation is what's most desparately needed for many projects.
But I wonder how difficult it was to convince the publisher of this, who must have wanted to flip the situation around, and only offer the 'soft' information for free.
--
The real Webmaven is user ID 27463. I don't rate an imposter, because my ID is such a lame-ass high number.
First, there's a pretty grievous error in the inetd config line he gives which makes the server not run. I can't remember the entire line but remove the duplicate 'cvs' text.
Second, although I know it doesn't fit in with the theme of the book, there isn't much in the way of setting up CVS for commercial use. In my case, I want to have CVS controlling both some OS and commercial code. Setting up SSH access, multiple CVS servers, access control, etc are not covered very well, if at all. Unfortunately, these are the same topics the Cederqvist doesn't cover either. I was hoping this book would fill in those gaps but it just doesn't.
On the upside, the author frequents the cvs newsgroup so you're likely to get book questions answered there (the group is pretty good for questions in general as well).
The same problems I had with trying to learn Expect, I had trying to learn CVS: lack of good online tutorials & documentation.
Richard Stallman (a man with whom I disagree on a great many topics) said it best: He had heard so many good things about Perl, and wanted to learn the language, but when he started looking for online tutorials, the ones he found were far and few in between, and not to mention of very low quality. Everybody kept telling him to buy the (O'Reilly) "books", but he wanted online stuff, stuff that just wasn't available.
When I wanted to learn Expect, I asked around, and posted to the newsgroup, on where would be a good place to learn, everybody replied, "get the Exploring Expect book." When I told them I couldn't afford it, I just got a "tough luck" and a shrug.
I have been wanting to learn how to use CVS for quite some time now, and I'm sure this book is great for someone that can afford to shell out the $40 bucks for it, but I can't, so can anyone point me to some good docs?
--
N. Thomas
Our program is cross-platform (Win32/Solaris); I don't know if VSS clients are available for Solaris (or any non-Windows platform), but a nice thing is that the CVS command-line tools are the same on Unix or Windows. Some of us use WinCVS on Windows. It's even possible to integrate CVS with Developer Studio by customizing some menus. There's a page out there detailing this, if you're willing to search for it. Of course, CVS can be integrated into Emacs on either platform as well.
One nice thing we use is the webCVS interface, which allows browsing the CVS repository in just about any web browser. One handy feature is its ability to display color diffs of arbitrary revisions.
If you're using strictly MS tools and you're not dealing with a lot of files, then VSS should do OK for you. Visual C, VB and family make it very easy to check files in and out of VSS, and it also makes it easy to deploy content to IIS based web sites. (although I know nothing about how secure that is)
If you're dealing with a large project, I think that it greatly increases the chance of the VSS database corrupting, which to me is one of the biggest flaws and a major reason why I would not use VSS.
The advantages of CVS are:
Simple file format eliminates chances of corruption. I've moved our repository to 3 different machines without any problems...I just had to tarball the cvs root directory and move it.
Support for multiple OS's, including a VSS-like client for windows
Comes by default with many Linux distributions, so all you have to do is dig up that old 486, put a good size HD on it, and you have instant version control.
Conflict resolution works just as well as VSS, if not better.
No license fees. :)
I have used both systems, so I'll comment on my experiences. I haven't administered a CVS repository, so some of my knowledge will be incomplete there.
The migration process question is easy to answer: when you migrate, you're gonna lose all your history. So when you do, I recommend you burn a CD with your VSS repository on it and archive it on a server somewhere. Then, do a complete checkout of your source tree into a fresh location. From there, do a massive add to your CVS repository and boom, you've got your source migrated over. One thing you may want to do is write a script that will insert an $Id:$ tag in a comment up at the top of each of your source files before they get added; I find it awfully nice to have the revision number right there so that when somebody asks me what version I'm working on, I can tell 'em.
On the differences, an exhaustive list would be really long. You might take a look at the FAQ for comp.software.config-mgmt as a starting point. In brief, though, CVS has these advantages over VSS:
Actually, if you can afford the package, I'd suggest looking into Perforce. It's very similar to CVS (including the variety of platforms for which it has clients - although the Mac client is an MPW tool, which is great for programmers but icky for designer types), and it introduces a couple of very nice features: atomic changes (so when you check in a bunch of files, the commit doesn't happen until they're all in) and a really slick use of the filesystem so that with really huge repositories it's still lightning fast.
Oh, go on, check out my job.
in VSS you have to lock the file before you can can change it
Not necessarily true. When the administrator sets up a VSS database (repository) s/he can enable multiple checkouts, so multiple developers can have concurrent modify access. When this happens then the conflict resolution is the same as in CVS: the second and subsequent checkins have to do a diff to resolve the possiblity of conflicts. The builtin diff tool is pretty cool, but it doesn't let you make decisions in situ. Still, I worked at a shop where there were 5 developers working on the same codebase and the automatic merging worked very well for us. Note that this works fine for things like C, where local changes tend to be locally scoped, but it is lousy for things like HTML or PostScript where local changes tend to have global scope.
Oh, go on, check out my job.