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]...
If some of the chapters are being released under the GPL, doesn't that make the whole book a derived work...which would also have to be released under the GPL?
------
------
You are in a twisty little maze of open source licenses, all different.
.sig: file not found
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.
BOFH, My model for being a sysadmin :)
As a matter of interest, do projects using CVS find that the builds of software projects get broken under a concurrent development scheme, as changes by others working on the same files may have unforeseen side effects not picked up by the automated merge tools?
And on a related line of inquiry, do race conditions every occur on busy projects where by the time you have merged and tested the latest additions to some file, someone has already checked in yet another update to a file you are working on forcing you to do another round of merging and testing?
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
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.
The so-called "release it early, release it often" model of open source development is quite simply a load of nonsense, and not one that anybody engaged in a project which they want to ever complete should bother with
The "relase early, release often" model is the very soul of Open Source Software. Eric Raymond, in his landmark Cathedra l and the Bazaar , which lead directly to the start of the Open Source Revolution, wrote so much, and am I to believe that you are more knowldgeable than the inventor of Open Source?
If you have some ivory tower ideal in which bug are found as soon as possible, then you end up spending all of your time fixing these bugs (because all open source does is let more people complain about bugs)
As Mr. Raymond said, "Many eyes make all bugs shallow", once again proving he is right. Open Source Software rarely has bugs do to it's very nature. OSS programmers make fewer, if any, mistakes than their commerical counterparts, and scientific studies have backed this up.
Let's face it, how many open source projects ever get anywhere? Apache and Linux are the only two that I can think of
Fetchmail is a very sucessful Open Source Projects which from Eric S. Raymond. I use it all the time.
On the other hand we have vapourware like ext3,
wishware like the GIMP and crapware like Mozilla to try and keep us going.
Well, I heard that ESR will be working with the Gimp's Scheme code (since he helped to write Scheme), but I haven't heard anything about his involvement in the Mozilla project since the early days of it. He hasn't even mentioned ext3, so I can't comment on it.
All I can say is thank God for Borland, leading the way in allowing corporate interests to migrate to Linux.
I'm just hoping they'll become interested in NetBSD!
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).
Could somebody please post a summary of the differences between CVS and VSS?
Also, if I were convinced to switch to CVS, what would the migration process consist of?
http://sourceforge.net/
The author actually includes several chapters which relate specifically to the development of Open Source Software. So here, the distinction is actually relevant.
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
I've found that Cervisia is a _very_ nice GUI frontend for CVS.
Check out
http://cervisia.sourceforge.net/
There is still room for improvement and more features, but it does make dealing with CVS less painful.
I like the fact that it shows you the commands it is executing so that you can learn as you go.
eli173
"I don't care so much about feature X, but if you want it, then you write the code for it."
Where's the problem?
--
send all spam to theotherwhitemeat@ropine.com
Look into Ant, the XML based build tool from Apache.
It's still in its infancy, but the idea is solid I think. Just needs to be developed more.
One feature that I would like to see is the ability to configure the diff algorithm by file type, so that revisioned binary files (images, for instance) can be stored in the repository on a space-efficient manner. PRCS does this with the xdelta library, but I don't know if PRCS allows the use of a line-oriented-text diff algorithm for source files.
I also find the event hooks in CVS to be lacking. A generalized hook mechanism is needed that has access to both the name of the checked-in file and its contents, with both pre-commit and post-commit triggers, by file name, file type, directory, module, user, and whatever other parameter might be useful. CVS has some of this, but not enough.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Have you ever actually tried controlling air traffic? There's no comparison between ATC and CVS, other than perhaps that they are both TLA's.
With open source development, you can always take a break. If you turn your eyes away from your code to check the latest news on Slashdot, nobody dies.
But air traffic control...dammit, man, those planes! They just keep coming and coming! Make them stop!
Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
there isn't much in the way of setting up CVS for commercial use [...] I was hoping this book would fill in those gaps but it just doesn't.
*boggle*
What part of Open Source Development with CVS did you not understand? Why would anyone expect this book to cover commercial software?
"Hey, this book is titled Tips for Baking Chocolate-Chip Cookies, so I'll purchase it because I'm hoping it will also cover meatloaf."
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Microsoft at least used to use an internally developed tool called "SLM" ("shared library management", maybe?). It was command-line oriented, and as I remember it, it did file locking by default (when you have a file "checked out", no one else can until you do a "check in").
Anyway, Source Safe didn't exist when they started using SLM, and I wouldn't be suprised if the developers just never felt like switching version control software just to be dogfood-compliant.
(A better question might be, if SLM is so useful, why didn't they ever ship it as a product? My experience with it was that it was kind of balky to use, but I later realized that all source control systems are -- certainly including CVS.)
But then my only experience with using Source Safe was that the guy administering it couldn't figure out how to give someone permission to check something out. It was a little *too* safe... things would go in, but never come out again. (We went back to using CVS.)
Brian
I know perfectly well what CVS is for. I use it daily. You are responding to the wrong parts of my message (because you feel cool doing so, or something).
Let me try again. Read carefully. The book is not about "how to use CVS". It is not about "how to apply CVS to whatever you work on". It is not the CVS manual. It is not, repeat NOT, addressing general development issues like CVS does. CVS != this book.
The book is specifically targeted towards open source development. The first poster's complaint was that the book -- NOT CVS, JUST THE BOOK -- didn't treat proprietary stuff. My point is that the book -- NOT CVS, JUST THE BOOK -- made no claim of treating proprietary topics.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
> The so-called "release it early, release it often" model of open source development is quite simply a load of nonsense
So, what release model do you use for your OSS project, and what are the pros/cons of using your model vs the RO2 model?
--
Sheesh, evil *and* a jerk. -- Jade