On Fri, Apr 15, 2005 at 03:31:17PM -0700, John H. Robinson, IV wrote: > On another list, someone pointed out how Subversion is superior to CVS > in most every regard. I'd like to bring that discussion here, to a > larger forum. >
I was one of the ones who sort of started this, so I feel compelled to answer. However, because the challenge has been proposed in mature terms (damn your eyes, jhriv! ;) I wand to be balanced and factual in my response. That takes more effort than shooting off my mouth. First, let's distinguish between file archiving and Software Configuration Management. True SCM on a professional level is a set of imperatives expressed in process. Tools only contribute. In fact, one of the chronic problems in the SCM world is when comfort with a particular tool begins to direct the thinking of the people doing the job. SCM tools have evolved over more than 20 years, and as we would expect, there has been a degree of progress in them. No one I can think of would suggest that anyone use or learn SCCS, for example. Its day is long gone. There was a time, however, when it was state of the art. So what do we want from an SCM system? Here is a short and incomplete list. - code recovery to any committed revision - tagging/labeling allowing recovery of full code sets - support of different lines of development - support of maintenance (not always the same thing) - prevention of code overwrites to both the repository and the work area - rational merging mechanism for changes in code committed - support for all development modules (binary as well as text) - locking mechanisms to prevent overwrites of nonmerging modules - granular security to allow administrators to configure the repository for different levels of access - extensibility through scripting and triggers - visual tools to improve presentation of complex data - auditability to satisfy regulatory bodies internal and external - job/bug/issue/requirements tracking that associates changes with issues to the line of code and to the commit If you're at all familiar with RCS, you'll immediately concede that it won't make the cut. Mind you, I'm a great advocate of RCS for file archiving, and will in a separate email address methods for doing exactly that with RCS. RCS belongs in everyone's kit of tools IMHO because of its smallness and flexibility. It is to SCM what lynx is to browsers -- an essential tool that is not necessarily the first choice. Now in all honesty, the best tools I have reviewed and used are commercial products. My company is presently using Perforce (http://www.perforce.com), and I'm very happy with it. You should know that Perforce the company lets you download a 2-person license free to play with, and will give any open source project a free license; so unless you have religious reasons (God told RMS that man should eschew profit from Software), it's worth looking at. Perforce is kind of a sports car. In the road grader category, I fancy Merant's (haven't they just gone through yet another acquisition/name change?) Dimensions. *Big*, expensive although not compared to ClearCase (the national debt is cheap compared to ClearCase), task driven, looked to us like a good product for those who want the Big Solution. But the real question posed here was CVS vs SVN. So let's see if I can encapsulate my reasons for preferring SVN so much. CVS: Upside: - everybody is using it and is familiar with it (_really_ weak argument to me) - umm ... umm ... OK, no more upside Downside: - not truly C/S with lots of consequences. All state is client side, and if that gets confused, you're screwed - security is a sick joke. Have you _looked_ at how they do it?! - terrible handling of binary modules - lack of atomic commits -- lose your connection halfway through a commit, and both you and the repository need to go to tape - poor support of file renames (you lose history) - no support of directory restructuring - kludgey and slow triggers. You end up doing hopelessly slow recursive loops over directory structures - expensive operations, especially branching and tagging. The bigger the repository, the longer it takes - no real privilege granularity (maybe through triggers, but do you want to be spending your time making CVS work, or coding?) Sooo ... most projects in CVS are r/o with contributors emailing patches and some poor snook of an admin merging them, tagging, branching, and generally catching hell because s/he's too slow etc. Now, Subversion: Upside: - mostly a drop-in replacement for CVS (i.e., most users won't have to relearn much) - everything I mention above has been fixed - the "everything is a copy/snapshot" paradigm is simple and flexible - revisions are by commit, not individual to each file - because of URL design for defining repositories, webDAV enabled from the get-go - data base design (Berkeley DB) allows hot back-ups, inexpensive (fast!) operations - I personally find the mailing list and community for Subversion a lot more pleasant and less cliquey that the CVS community, which tended to be disparaging and nasty Downside: - because it's a drop-in for CVS, they may have missed the chance to do some things really new - requires Apache 2 for webDAV (I don't know much about this, but I list it because I know it bothers some people) - has a reputation for dependency problems with several current distros (the developers have decided to stick with the latest in everything) - requires people to change (see http://sial.org/howto/subversion/cvs-migrate/) Now I'm sure I've missed something on both sides of both, and when the Subversion web site comes back up (not responding right now, but usually at http://subversion.tigris.org), you can check it out for whatever else they emphasize. SVN also has a suite of other tools supposedly integrated, including issue tracking, but I haven't evaluated them. I have as a consultant installed and supported CVS at a fair sized development operation. I did this before SVN was available. Based on that experience and even if SVN hadn't finally shipped stable, I would not use CVS again in a professional arena. I would tell a client to either pony up the cash for a real system or get another boy. But I would have no compunctions about using Subversion professionally based on my experience with it so far (no webDAV or issue tracking tests so far). I will add that I find the dependency stuff very annoying. I dealt with it in my usual fashion -- by waiting until Red Hat distributed it (FC3 and later). Even with that, I haven't been able to make any of SVN's GUIs load, so they're untested so far, too. I would strongly suggest that CVS has outlived its usefulness. Know how to use it, sure; to allow yourself access to all the old CVS archives. But if you're setting up a new project, do yourself a favor and learn Subversion. It lives up to its mantra of being "a compelling replacement for CVS." -- Lan Barnes [EMAIL PROTECTED] Linux Guy, SCM Specialist 858-354-0616 -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
