Open Source Development with CVS 127
| Open Source Development with CVS | |
| author | Karl Fogel |
| pages | 316 |
| publisher | Coriolis Open Press |
| rating | 8.5 |
| reviewer | chromatic |
| ISBN | 1-57610-490-7 |
| summary | More than a summary of CVS commands, Open Source Development with CVS is a study of how to organize and lead free software projects. |
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 Contents
Purchase 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
CVS as the standard? (Score:3)
GPL (Score:2)
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?
------
Constant release model? (Score:1)
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.
give us a break (Score:1)
But, come on now, this article is just an add for think-geek.
This seems really cool (Score:2)
Re:CVS as the standard? (Score:1)
More importantly, you aren't stranded when the company that owns it gets bought out by a competitor who give you an uncomfortable migration path to their product. That would be the competing product you rejected last year because it didn't do what you needed. And speaking of that, like all other GPL'ed projects, if you need a feature, add it, or offer to support a development team that will.
CVS at work (Score:3)
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.
Re:GPL (Score:3)
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.
Execellent Book (Score:4)
Broken builds under concurrent development? (Score:2)
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
Why certain chapters were open sourced (Score:4)
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.
--
To be blunt, CVS sucks (Score:1)
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.
Re:CVS as the standard? (Score:2)
Excuse me? VSS *sucks*. Ok, it might be reasonable for one, *maybe* two people absolute max. We're (trying to) use it for ~30 people and it is awful...
CVS, OTOH, is a wonderful tool. I haven't had to use it in a group of more than a half-dozen developers, but it holds up well, provides a better security model, and is truly cross-platform (the win32 clients work quite well). And I must say that this book has been a valuable reference. If you have to admin CVS, definitely get it. If you are just using CVS, get one or two copies for the group to share.
Re:give us a break (Score:1)
--
Re:Why certain chapters were open sourced (Score:1)
If all you really want is the technical information, you can get all of this from online sources (and print it if you want a hardcopy). The thing that made me buy the book were the chapters on the philosophy of open source project management.
Re:Constant release model? (Score:2)
The "relase early, release often" model is the very soul of Open Source Software. Eric Raymond, in his landmark Cathedra l and the Bazaar [tuxedo.org] , 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 [tuxedo.org] 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! [netbsd.org]
Re:CVS as the standard? (Score:1)
Where's the online book? (Score:1)
Has anyone actually been able to get to it?
Bad link?
Slashdotted?
Re:CVS is a very serious condition (Score:1)
CVS rocks (Score:1)
Re:Flawed (Score:1)
Re:To be blunt, CVS sucks (Score:1)
Um, yeah, and if you happen to think that "rm" stands for "RenaMe", you can also get yourself in trouble. This is kind of a sore subject for me, because a number of people where I work loudly and consistently preach the virtues of supporting user stupidity. "Oh, if they set this environment variable and used this command-line option and delete the temporary file, the button might be an ugly color! Lock it down!"
At some point, you have to stop trying to protect users from their own stupidity. Especially admins, come to think of it. Anyone who ignores the instructions in the manual (freely available [cyclic.com] btw) shouldn't be administering anything, let alone the version management system for a multiple-developer project.
Face it: system administration can be hard work sometimes. Doing anything right can be hard work sometimes. If you don't know how something works, learn! Most any package comes with something, and there's always mailing lists, IRC channels, and newsgroups...
Re:CVS as the standard? (Score:1)
I know it's easy for CVS to be run over commonly-available secure connections like ssh. Does anyone know if that's possible with VSS, or would one have to go about setting up a VPN to securely communicate?
CVS hosting (Score:1)
Re:Why certain chapters were open sourced (Score:2)
--
Title? (Score:1)
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?
Somewhat disappointing book (Score:4)
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).
CVS vs VSS (Score:2)
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?
Re:Broken builds under concurrent development? (Score:2)
Yes. In fact, we've implemented a couple things at work to alleviate this. Some of the cvs commands have been abstracted into a script. You can't commit changes to the repository unless you put a lock on it first with a new command. Once in a while things still get stomped, but it's happening a lot less frequently now.
Re:CVS hosting (Score:2)
Anyone have feedback on BitKeeper? (Score:1)
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 [bitmover.com]
Re:Broken builds under concurrent development? (Score:1)
NOTE: Peter Miller's Aegis appears to deal with this specific problem.
2) Yes. This sort of thing happens periodically, but not in the manner you describe. For individual files, cvs appears to do a good job with concurrency. Problems like this arise when configuration management branches the code and doesn't adequately notify the developers. This results in fixes being checked into the old branch. Unless the developer or cm person is diligent, the new branch *won't* have the fix.
It's a joke, you nitwits! (Score:1)
--
Change is inevitable.
Re:Title? (Score:2)
Re:Flawed (Score:1)
Re:give us a break (Score:1)
Re:Execellent Book (Score:2)
Damned fine book. (Score:1)
learning CVS (Score:3)
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
Re:CVS vs VSS (Score:3)
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 [fh-heilbronn.de] 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.
Short shrift to BSD? (Score:1)
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.)
Re:Broken builds under concurrent development? (Score:1)
You can also implement advisory locks too...
Cervisia (CVS GUI) (Score:2)
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
Re:Constant release model? (Score:2)
"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?
--
Re:GPL (Score:1)
Re:Constant release model? (Score:1)
I beg to differ. The true father of the Open Source Revolution is none other than Richard M. Stallman. ers is nothing but an outcast, a reject, with inferiority syndromes because his contributions were not of high enough quality to be included in the allmighty emacs [emacs.org].
OSS programmers make fewer, if any, mistakes than their commerical counterparts, and scientific studies have backed this up.
Agreed. Only I would have chosen the British spelling: commercial.
Fetchmail is a very sucessful Open Source Projects which from Eric S. Raymond. I use it all the time.
But isn't emacs a much better example? It allows you not only to fetch mail, but to read it as well. Furthermore it allows you to read news, compile and even execute programs, play games and it is self documenting too! I hope you see the error of your ways and are more careful in the future when choosing who you listen to.
I'm just hoping they'll become interested in NetBSD!
Aha! Another indication of your ignorance, although I do not blame you. You have clearly been misguided by that blasphemous esr.
As the wonderful Richard M. Stallman says here [gnu.org] NetBSD [python.org] has numerous problems with its license, including even advertising clauses! Well, so much for Open Source Software.
Thank you.
Re:CVS vs VSS (Score:4)
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 [wincvs.org]
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. :)
Re:You are kidding.... (Score:1)
I guess you have to add me to that count =)
Re:CVS vs VSS (Score:3)
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 [honeywell.com] 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 [perforce.com]. 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.
Re:GPL (Score:1)
It's still freely available via anonymous CVS. See http://cvsbook.red-bean.com/anoncvs.html [red-bean.com] for instructions on getting it.
The CVS version is the texinfo format, and includes a Makefile to build the alternate formats.
Re:learning CVS (Score:1)
Re:To be blunt, CVS sucks (Score:1)
User education isn't the issue - CVS simply lacks adequate functionality.
Major source tree cleanups, as another poster has pointed out, are incredibly painful, and typically result in the admin going into /CVSROOT and just tickling the filesystem directly (which is what any type of database should prevent you from having to do).
Moderators: How is this a troll? (Score:1)
Re:Broken builds under concurrent development? (Score:1)
additional:
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?
Only if 1) Your developers don't talk to each other or 2) Your files don't map to the modular chunks of the system the developers are working on.
Most of the time, developers are working on separate functionality in separate files; when they overlap, you talk to each other...
CVS probably implies a build system broken into lots of files along natural system module breaks, but then you probably ought to be doing that anyway...
Re:Where's the online book? (Score:1)
It appears that pretty much all the links to the free chapters are currently bad. Since they're all dead, and there's no mention of it on the site, I'm guessing it's due to a mistake. Especially as they were all working a week or two ago.
However, it's still freely available via anonymous CVS. See http://cvsbook.red-bean.com/anoncvs.html [red-bean.com] for instructions on getting it. (I just tried it, and it does work)
The CVS version is the texinfo format, and includes a Makefile to build the alternate formats.
Re:Broken builds under concurrent development? (Score:1)
Ha! Would that it were. :-b
Chatty protocols (was Re:CVS vs VSS) (Score:1)
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?
Re:CVS as the standard? (Score:1)
Luckily, we only have three or four people using VSS here.
It really is a joy to use, though, if you're using visual interdev. (I wonder if they named that to try to steal the name "vi"?) Since you can check files in and out from the project pane, it's very very convenient.
Re:CVS as the standard? (Score:2)
And if you want something superior to CVS, but without the financial hemmorage that is ClearCase, get Perforce [perforce.com]
Re:GPL (Score:1)
Re:To be blunt, CVS sucks (Score:1)
Re:Flawed (Score:1)
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.
Re:Flawed (Score:1)
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.
Re:learning CVS (Score:1)
I think the proper "free" response to this is to say.. "What do you want for free?" If you don't like it write your own documentation...
Re:CVS vs VSS (Score:1)
It's one thing to say they don't use VSS; It's another to back it up by telling us what they do use. So, uh, what do they use?
Re:CVS vs VSS (Score:1)
Re:Moderators: How is this a troll? (Score:1)
Re:Broken builds under concurrent development? (Score:1)
Ha! Would that it were.
:-) In an ideal world that is...
Advisory locks at least stop people unwittingly editing the same file. The paranoid can use mandatory locking...
Re:To be blunt, CVS sucks (Score:2)
It's still in its infancy, but the idea is solid I think. Just needs to be developed more.
Richard Stallman learning perl (Score:1)
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
Re:CVS as the standard? (Score:1)
More about SourceOffSite here [sourcegear.com].
Book's web site fixed now (Score:1)
cvsbook.red-bean.com [red-bean.com], the problem is now fixed.
-Karl
Re:learning CVS (Score:1)
I spent $40 or whatever on O'Reilly's _Programming Perl_ and while I consider it money well spent, the most consistently referenced chapter (and the only one I can claim to actually need) is Chapter 2, which lists all of the functions that Perl has and uses, which is a direct conversion from the manpage, right down to the typos.
Re:Why certain chapters were open sourced (Score:2)
publisher wasn't comfortable with that. However,
they were enthusiastic about making the CVS-
specific portions of the book free. In fact,
they may have suggested it before I did.
I think the logic was that CVS is free, so the
documentation about CVS should also be free.
It was certainly more important to me that the
CVS portions be free than the rest, although I
wish the entire thing could have been free.
Deep down, I think intellectual property is
a contradiction in terms, but in order to get
this book published I made a compromise.
Fortunately, it looks like Coriolis has no reason
to regret their agreement to release the majority
of the book for free. Sales are doing well, and
it's already into reprint. Long live dead trees!
-K
Re:learning CVS (Score:1)
Re:CVS vs VSS (Score:2)
My personal opinion is:
Use CVS for open source projects. When one developer starts work on a file and then doesn't have time to finish, other people are not hindered.
For commercial apps I prefer the VSS-style. You know your working hours and your holidays, when you start working on a file, you will usually finish it. If you don't, you can still give it back. If someone needs a file somebody else is working on, its no problem contacting the other person (this might be a problem with open source). I don't say, use VSS. There are many VSS-like programs out there. For example, in my old company (>=7 years ago) we used PVCS, which was already quite nice. In my current job we work with VSS, which is alrightish (we only have 2.5 developers
Re:To be blunt, CVS sucks (Score:1)
Re:To be blunt, CVS sucks (Score:1)
Will the FAQ tell me why CVS is unable to rename files easily?
Re:To be blunt, CVS sucks (Score:2)
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.
Re:CVS as the standard? (Score:1)
I'll chime in here and share my experience.
I use both CVS (on Linux and NT, 2 users) and SourceSafe (on NT, 40 users) constantly. I've also used ClearCase (on Solaris and NT, 20 users) for two years.
I also maintain and administer CVS (for a project a buddy and me are working on).
ClearCase is extremely powerful, but is has its own filesystem and is so complex, my group had many problems with it. I also found the performance, even over a high-speed LAN, crummy. I know there are snapshot views, but we found them problematic. ClearCase is probably well-suited to
huge legacy systems supporting multiple concurrent
releases, but it's expensive (I hear > 100,000 per year for my company) and very difficult to administer (probably need a person who does nothing else). Distributed development over many cities seems unlikely.
SourceSafe is easy to use and better than most Microsoft products (of course, they bought it rather than develop it in-house), and even supports distributed development through an add-on
called Source OffSite. But it's not cross platform, can't be administered remotely and is primarily GUI-driven (although I hear some things can be done from the command line). The biggest complaints, which I haven't seen myself yet, are that it doesn't scale well, nor does it properly support multiple branches well -- which ClearCase does.
CVS has been an absolute pleasure, and I administer it myself from 600 miles away where it is hosted on an old Pentium 200 running Linux. The online chapters of the CVS book have been extremely helpful. Even a newcomer like myself has been able to set it up. Plus, with the wonderful web front-end, CVSweb, as well as TkCVS, it's as easy to use on the client side as SourceSafe. I can't speak to the scalability or branching management personally (although large projects that use CVS do), I find it offers the best of both worlds -- configurability and ease-of-use.
Re:CVS hosting (Score:1)
//jt
-------------------
Community Relations
OpenAvenue, Inc.
http://www.openave.net
Re:learning CVS (Score:1)
//jt
-------------------
Community Relations
OpenAvenue, Inc.
http://openave.net
Re:CVS vs VSS (Score:1)
CVs *is* good if... (Score:1)
Re:Can someone tell me (Score:1)
Re:To be blunt, CVS sucks (Score:1)
Check out BitKeeper (Score:1)
The licensing is a bit wacky, as it's not exactly free.
ATC (Score:2)
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!
Re:Somewhat disappointing book (Score:3)
That's interesting. What operating system are you running?
Here's the line that I think you're talking about:
cvspserver stream tcp nowait root
--allow-root=/usr/local/newrepos pserver
The inetd implementations I'm familiar with would require both "/usr/local/bin/cvs" and "cvs" in that line. The first tells inetd where to find the binary, and the second is the first argument in the command-line invocation. If there are inetds floating around which choke on that line, you should definitely report it as a documentation bug.
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.
I will venture a guess that Karl didn't cover those topics because he didn't think it necessary.
If I were setting up a CVS server with projects that needed different levels of access control, I would probably put them into completely different repositories. Put your free code into
Disclaimer: I was one of the technical reviewers for the book and so am not objective about its quality.
CVS Dogma (Score:1)
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?
Re:To be blunt, CVS sucks (Score:1)
Um, what were you expecting? (Score:2)
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."
Oh, how magical! (Score:1)
Gaaaah!
Re:give us a break (Score:1)
Re:CVS vs VSS (Score:3)
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.
Microsoft probably uses an internal tool called SL (Score:2)
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.)
Re:To be blunt, CVS sucks (Score:2)
Brian
You're missing the point (and you're rude). (Score:2)
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.
Re:Constant release model? (Score:2)
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?
--
Re:CVS as the standard? (Score:2)