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.
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.
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) and trying to satisfy vocal Linux "hackers" who want feature X, compatibility with program/desktop/window manager Y or whatever by spending additional time doing this in an attempt to deliver.
Let's face it, how many open source projects ever get anywhere? Apache and Linux are the only two that I can think of, and that's because they got in before everyone jumped on the bandwagon. On the other hand we have vapourware like ext3, wishware like the GIMP and crapware like Mozilla to try and keep us going.
All I can say is thank God for Borland, leading the way in allowing corporate interests to migrate to Linux.
But, come on now, this article is just an add for think-geek.
.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.
To this day, most usrrs and admins resolve CVS problems by mucking with the /CVSROOT files themselves, and just taking it from scratch. It is incredibly easy to get CVS into a confused state, particularly when removing or moving files.
Gripe mode off.
Has anyone actually been able to get to it?
Bad link?
Slashdotted?
This the funniest post I have read in ages, would you people moderate that post up to 6!!!!
duh!
"Skill shows through where genius wears thin." -Wittgenstein || Religion: uniting aviation and architecture.
Agreed. I want my work done 5 minutes ago, now I have to deal with a corrupt repository? For CVS, you haven't used WinCSV, have you?
Is there such a thing?
What's up with the title? I mean, is there any substantial difference between "Development with CVS" and "Open Source Development with CVS"? The process should be the same regardless if it's only in-house or throughout the 'net. Right?
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?
BitKeeper is a source management system that claims to be "especially tuned to the needs of the Linux team". It has some interesting features for distributed development. The "trees of repositories" looks particularly useful for open source projects.
I'm impressed with what I read about BitKeeper, but since CVS does the job for me I've never tried it. Anyone used it?
You can get more info here
n/t
--
Change is inevitable.
Change is inevitable.
Progress is not.
Correction: 'Point and Click' Power User ;) CVS and SourceSafe aren't really competing apps. Yes, they have the same general purpose, but they fullfill this in two very different environments. If you're cracking out anything related to these MS buzz words, use SourceSafe. If you're programming in c or Perl or something else in Unix, CVS is by far your best bet.
I read this book cover-to-cover a few weeks ago, a definate rarity for me; a lot of times I'm lucky to get to the 2nd chapter before giving up. The author spiced it up pretty good with Open Source anicdotes and human language. I walked away with more than an understanding of how to use CVS.
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 acutally did buy a copy of this book, and to the limited degree which I've been able to read it (life? what life?), it's been quite enjoyable. However, I do have one beef with the author.
In his initial description of what constitutes Open Source, the author describes OSS licenses as falling into one of two broad categories: the GNU Public License, and "everything else". Given the constant flamewars which seem to erupt over "which is really more free," I would have thought that a mention of the BSD license as an alternative was appropriate.
Is it a critical flaw? Probably not. Anyone interested in OSS enough to purchase this book has probably already heard of the BSD license. But it bothered me to see the GPL presented as the be-all, end-all when there are other licenses with substantial differences and large followings.
(disclaimer: other than a mild personal preference for the GPL, I have no opinion on the relative worth of either the GPL or BSD license.)
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 guess you have to add me to that count =)
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
Once again, the /. group-mentality rears its ugly head.
Speaking of chatty protocols, has anyone noticed the response string that a remote CVS server gives after authenticating a client? If your login is accepted, it sends back "i love you", if it's rejected, you get back "i hate you". I wonder what the story behind that is?
I don't care if it's 90,000 hectares. That lake was not my doing.
But why on Earth would anyone want to use Perl for a project which is going to be large enough to require CVS? So much bullsh*t about Perl is spoken on Slashdot and Usenet, and it's starting to annoy me. Here are the facts:
1. Perl is slow. This fact will become obvious once the Perl program becomes sufficiently large. Compiled languages are the only serious option for coding any non-trivial software.
2. Perl makes inefficient use of available resources. The interpreted nature of Perl creates a huge overhead, thus wasting processor resources and making your 1GHz Athlon perform like a 486.
3. Perl is hard to maintain. It is impossible to create weakly-coupled, highly abstracted code in Perl, thus it is also impossible to maintain Perl code on large projects. Object Oriented languages win every time.
4. Perl is unecessary. There really is no sane reason to use Perl - The argument that Perl is simpler to learn is completely invalid, since any reasonably skilled Perl 'coder' can easily make the step up to C. The sheer inefficiency of Perl means that C and C++ are more suitable than Perl for 99% of programs.
Please don't moderate this down because it disagrees with your own beliefs about Perl. The truth is, everything I've said can be backed up with facts.
- Lita Juarez.
If you mean WinCVS, it's ass. On Win98, Win2k, and NT4, it managed to sometimes botch perms and sometimes not at my last place of work. This is really fun when you have six people working on a website.
That said, I can see some real uses for CVS, especially in a web development environment; You can set up a cron on your remote server to periodically do a CVS update. rsync is better at moving files around, but CVS does it all in one package.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Gah. Perl comes with some of the nicest, most complete, and entertaining man pages that I've ever seen in a software package. I don't believe there's a reason to complain about the lack of perl docs.
I was slightly disappointed when I finally went out and bought one of those O'Reilly books after using perl for a year or two, and found that much of it was pulled straight from the man pages.
Perhaps old rms was trying 'info perl' instead of 'man perl'.
-joel
Apologies for the broken links at
cvsbook.red-bean.com, the problem is now fixed.
-Karl
http://www.red-bean.com/kfogel
You don't get hung up on the the word 'open source' and instead use 'distributed development', and avoid getting hung up on your love of VB, you'll find that CVS solves most of the problems that other version control systems can't touch. CVS is not idiot-proof, and is prone to pilot error. It needs to have some solid project management to avoid serious problems. But you know what, if you don't have decent development management, you have bigger problems that your source control solution. Here is why CVS is great: it's small, lightweight, works extremely esily with developers writing on multiple platforms, is amazingly easy to maintain when compared to the extremely cumbersome and slow solutions of other systems. Solutions like ClearCase and VSS require system configurations that take over major portions of both the server and clietn software, and make distributed computing nearly impossible. Have you ever tried setting up ClearCase to work for multiple offices in different states, and engineers who telecommute? It is nearly impossible. With CVS, you set up a repository, set up a pserver port, and blammo, any one that can get behind your firewall can access the source control sytem, from anywhere, with a very limited toolset. And build times are also trastically reduced. Try this sometime: do an export of your files in source control to a flat file system. I did. 20 minutes for about 10,000 odd files (java,xml templates, images and shell scripts) for CVS. About 4 hours for ClearCase. CVS is not the end-all be-all that many source control systems claim to be, but it also doesn't ahve a lot of the baggage that limit development flexibility those other systems have.
Yes, CVS will do this. It only does this when you are using reserved checkouts; but it is a configurable option like any other that you set up when you are outlining your development processes.
The licensing is a bit wacky, as it's not exactly free.
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)
Maybe somebody can explain this to me. I want to get a "non-working" copy of a module. I can do 'cvs export Module'. But if I later want to update my local copy and there are changes in CVS, I get problems and it refuses to do so. I can do 'cvs co Module; cvs release Module' and cvs update works fine.
And then what if I only want to check out a single file, work on it in the "non-working" directory, and then check it back in. Does CVS force upon you to work with modules by checking out the entire thing?
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)
Gaaaah!
WWJD? JWRTFM!!!
Even so, it's popularity is clearly growing and deservedly. It is _very_ easy to use, very powerful, and free. There is nothing quite like the feeling of creating a new free build environment instance that works across the hall from the baseline or around the world from it. I have even used CVS to manage source code updates into classified environments.
Could it be better? You bet. Would I use anything else? Not a chance.
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.)
Maybe, but clearcase costs $$$$$$$$ and CVS is free. Oh yeah, and the Redhat version of Clearcase refused to install on my Redhat 6.1 machine as I didn't have the text "redhat" in my /etc/issue file. (-:
Maybe VSS is an OK system for projects where there are very few developers, or only one person per source file, but it's terrible for working on a team project where everyone is competent enough to make changes to the entire source tree.
Support for multiple people editing the same file was added as an after thought, and it shows. For example, you can't check out a file without updating it first. Of course, if you have to update one file, then you probably have to update them all. This is really annoying if you're not current and need to change another file and not ready to update. Maybe the build is currently broken and you'd like to keep working while things are getting fixed. Or maybe you want to get your stuff working before dealing with the big merge you know you'll have to do when you update.
VSS also doesn't delete files that have been renamed or removed, so it's a big manual hassle to go through and clean out dead files.
It's also really frustrating that VSS hides everything in cryptically named files. Suppose you want to know who added or edited a specific line of code? You can't just look at the diff log, you have to manually run diffs between versions until you find the edit.
Finally, if you're going to complain about command line tools, I don't see how you can like VSS. Its command-line origins are clearly visible. There are many operations that can't be performed via the GUI, you have to drop back to the command line.
I don't know much about CVS, but I do know that if you think VSS is a good solution, you've never used a good source control system.
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)
I agree, I'm not much of a troll. Hell, I almost have positive karma!
:)
.sig to change...
But at least I'm not a baboon.
Oh, and BTW, I know how to spell grammar; yes, I am pink, but I am not swollen at the moment; yes, I probably can suck a dick, but I'm afraid I don't want to; and I'm sorry, but I am not into gay porn.
Now if you'll excuse me, I have some karma to lose and a
That said, I think it's time I changed my
VSS is great evaluation-ware (better than demo-ware). After using it for half an hour, you'll be convinced that it does everything you need. After you've made the commitment, you'll discover otherwise.
VSS uses an extremely chatty protocol (good old DCOM), so I find VSS unusable offsite. Latency is terrible. Over ISDN, it takes five minutes to navigate to the proper subfolder, check out a file, and check back in a modified version. Many at my office buy the third-party Source Offsite: their proxy translates into a more sensible protocol for their own client.
You'll also need a third-party client if you want to build your code on anything but Windows(TM). We must build on NT, Linux, and Solaris, so all our Unix synchronization was scripted by hand, to selectively update from Samba mounted drives. In effect, we've build our own source-control system alongside VSS.
We've found that the only safe way to synchronize a working copy of a VSS directory is to delete the entire branch of the tree and get a fresh copy. Otherwise, you'll never notice what files others have deleted or what new files you've forgotten to add to the tree. We've had the build break five days in a row for this very reason. When I check out files, I make a mirror copy of the directory under RCS, then use scripts to update VSS. My VSS tree is constantly deleted and refreshed to ensure real synchronization with the rest of the team.
The problem would be alleviated by changing "working folders" except that working folders do not work in any rational way. You'd like to switch between your polluted copy of a tree and a clean copy to check that your changes are compatible with others' more recent changes. You find that when you switch the working folder at the root of a tree, some sub-folders (sub-directories) remain with the old tree if files are checked out. You then discover that, by default, the same file will check out into one working folder and check in from another working folder. Yet time stamps and diffs make you think you checked in from the folder you put the file into and modified. Only when you delete and get a fresh copy of the tree, do you discover that you checked in the wrong version. To undo the damage, you must visit and reset every directory in the tree. You'll never try to change working folders again. (Everyone on the team tried it once and regretted it.)
As soon as we reach our next major milestone in August, we plan to switch to CVS. I used Clearcase for years and would also prefer it to VSS.
(Reality reasserts itself sooner or later.)
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.
I'm rude?? You're the person who *boogle*d at why the person complained!
Let me parse it for you again: The AC complained that the book didn't address proprietary software. You cased on him for expecting the book to, saying it only covered open source. I'm saying that to him and you: a) that the technical matter in the book applies to both open and closed source, and b) that claiming that it only applies to open source is ridiculous! Which is what your little analogy attempted to do.
The fact is, the book is an invaluable resource for CVS users and administrators, regardless of whether they're working on open or closed source. To claim that it only applies to open source because that's what's in its title is stupid.
use Sig::Witty;
We've been using CVS on our Linux server for over a year now to coordinate several on-site and offsite developers on our projects. I can't imagine life without it. It just works. On multiple platforms too!
My problem: I'd like to give our people the ability to use MacCVS/WinCVS/JCVS as a GUI for CVS usage. We can all plod along with the command-line tools, but let's face it, it gets repetitive, and some of our people aren't big on command-lines-via-telnet.
Is there a good Remote-CVS-for-complete-idiots guide somewhere? Our firewall is set up sort of tightly, so RSH/SSH is troublesome to get going. The docs for WinCVS and JCVS assume you already have the pserver setup and working, and I can't get even that going. I'm gonna go get this book tonight, maybe it will help. I've already read everything I can find on the web about remote CVS setups.
-- There is no truth. There is only Perception. To Percieve is to Exist.
..last post?
Mr. Last Post