Slashdot Mirror
Multi-User Subversion
chromatic writes "Rafael Garcia-Suarez has just penned an article about adopting Subversion for multi-user projects. (He also has a previous article on Single-User Subversion). With the recent release of Subversion 0.16 (see the File sharing link), the successor to CVS looks very good."
CVS is weak at best with a long standing list of quirks, bugs and missing features. The current architecture and code base is in such state where many opt to not make the attempt at crowbar many of these features and fixes into CVS. In CVS, security is non existant, branching takes up a lot of unnecessary resources and quite a great deal of time, lacks meta data like directory revisioning along with various other usefull items, stores useless CVS data in the repository and has a tendancy towards being slow. The worst, inexcusable, flaw in CVS is the complete lack of atomic commits.
On the flip side, I do not suggest using Subversion for any critical project at this point since they are not feature complete for their first release and their bug list, frankly, scares me.
If something goes wrong during a CVS checkin, then all hell can break loose.
Sex - Find It
A good discussion of this was in Linux Journal recently.
Briefly, CVS lacks version control across file renames, has some issues with binary files, and the CVS code base has serious design issues.
The fundamental design of CVS is flawed, and this leads to anomolous behavior. Becase the problem with CVS is in its design, not its current implementation, a re-design and corresponding re-write is reqiured.
For example, CVS stores its repository in a series of diffs in a directory structure, and the directory structure parallels the development tree. The difficulty is, directories in the cvs backend are therefore not versioned! Thus, moving files around, and re-working the tree, are not handled correctly in cvs. In subversion, the entire repository (dirs, files, and all) is stored as a single coherent revision; a subversion repository is an array of coherent tree/file groupings. As such, correct handling of directories occurs automatically. Also, atomic commits (something cvs lacks) are handled much more easily in this model.
Let me also say that the design of subversion is absolutely excellent. The design is properly decoupled and properly abstracted. Architecturally, it is greatly superior to cvs, and substantially superior to several commercial alternatives. I would imagine that the low-end source control products (PVCS, SourceSafe) will have significant difficulty staying alive once Subversion is widely deployed and tested.
Directory handling springs to mind, as does renaming files. Atomic commits too. As well, there's also the fact that you often end up editing the modules files directly - an end-user should never have to care about a program's internal storage of meta-data.
Now, I haven't used Subversion so I am unable to make a comparison. I understand it handles directory versioning better, but I'm not aware of the rest of the points I made. The directory handling alone is a huge plus however, so it's a project whose announcements I'm following closely.
Cheers,
Ian
Of course, no discussion of CVS's strengths and weaknesses vs. Subversion would be complete without mention of the third contender, arch. Link 1, Link 2.
I've been moving all of my CVS development over to Subversion over the past few months, including a couple development servers at my company.
Since Subversion is now in Debian unstable, it's really easy to install. Compiling from source is a bit of a hassle due to all the dependencies, especially on the apache2 libs.
So far, I've not had a bad experience. No data loss or anything. And I'm very, very happy that I can finally get rid of pserver.
Subversion impressed our company developers by its speed (subjectively, considerably faster than CVS for comparable operations) and its user-friendlyness. It's the details, stuff like automatic detection of binary files, that makes life for the dev people easier.
For the admin, the fact that it runs via apache2 makes your life much easier, especially when it comes to firewalling and access control (user and passwords, etc.) - in a corporate network, you could easily plug it right unto your LDAP server for authentication, for example.
Two things are holding Subversion back right now, IMHO:
a) lack of a wincvs/tkcvs equivalent. Rapidsvn is making progress, but it's still very much alpha.
b) a couple things still missing, like understanding symlinks.
Assorted stuff I do sometimes: Lemuria.org
Check out Aegis - http://aegis.sourceforge.net. It's better than Subversion. It's older than Subversion. It's more stable than Subversion. It has atomic multi-file commits. Branching to any depth. Multi-user support. Distributed support. Applying change sets to multiple repositories. And much, much more.
From the docs, compare with CVS. Remember that many of the Subversion deveoplers are/were CVS developers..
* Real copies and renames. The Subversion repository doesn't use
RCS files at all; instead, it implements a 'virtual' versioned
filesystem that tracks tree-structures over time (described
below). Files *and* directories are versioned. At last, there
are real client-side `mv' and `cp' commands that behave just as
you think.
* Atomic commits. A commit either goes into the repository
completely, or not all.
* Advanced network layer. The Subversion network server is Apache,
and client and server speak WebDAV(2) to one another. (See the
'design' section below.)
* Faster network access. A binary diffing algorithm is used to
store and transmit deltas in *both* directions, regardless of
whether a file is of text or binary type.
* Filesystem "properties". Each file or directory has an invisible
hashtable attached. You can invent and store any arbitrary
key/value pairs you wish: owner, perms, icons, app-creator,
mime-type, personal notes, etc. This is a general-purpose feature
for users. Properties are versioned, just like file contents.
And some properties are auto-detected, like the mime-type of a
file (no more remembering to use the '-kb' switch!)
* Extensible and hackable. Subversion has no historical baggage; it
was designed and then implemented as a collection of shared C
libraries with well-defined APIs. This makes Subversion extremely
maintainable and usable by other applications and languages.
* Easy migration. The Subversion command-line client is very
similar to CVS; the development model is the same, so CVS users
should have little trouble making the switch. Development of a
'cvs2svn' repository converter is in progress.
* It's Free. Subversion is released under a Apache/BSD-style
open-source license.
I wasn't going to bother, but the previous comment mentioning arch has been modded up to 4, so I'll speak a tiny bit of my peace.
... well, just follow the dev list closely.
SVN is a huge and complex system that aims, for its 1.0 release, to be just a tiny bit more featureful than CVS. There's quite a large number of bugs. The complexity for repository administrators is pretty high. The developers are willfully postponing consideration of a lot of deep issues in revision control. If you follow the dev list closely
arch is a tiny, simple system that aims, for its 1.0 release, to be way more featureful than CVS. Although I don't think its ready for deployment in large-scale situations, early adopters tell me that they enjoy using it. arch, unlike svn, is very well positioned to compete (with just a bit more development) with BitKeeper, ClearCase, and others. arch can do a hell of a lot for the commercial free software world with just a bit of investment.
And, I don't know how you should interpret this, but svn has a handful of paid developers -- arch has none and, in fact, I'm literally days away from homelessness.
Go figure.
Subversion does look somewhat better and cleaner than CVS. But there are lots of add-on tools for CVS that will need to get ported (GUIs, servers, web interfaces, IDE integration, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--CVS is used by many people who are not primarily developers, and the switch wouldn't be easy for them.
:)
Good point, but this is also a big concern of the Subversion folks. This is why subversion looks so much like CVS. The commands and aliases are almost all the same, and a great part of the comportment the users see also is.
The ViewCVS scripts has already been ported to SVN, though it's not perfect yet, it does work. The GUI is pretty much in development indeed : RapidSVN is a working one, yet not complete either. An Emacs mode, similar to the CVS mode, shouldn't bee too hard to code I suppose, this is just a matter of time, will, and knowledge of elisp
There was talkings about using SVN as a backend for a wiki too, this could be fun and really nice. A first draft had been coded by Greg Stein (if I'm not mistaken), but it was mostly test stuff.
Subversion still needs help and contributors. People keep whining about CVS not handling file renaming etc, and they also keep using complicated tricks to avoid those flaws. I know, I've done it too. The very same people look at subversion and say "mh, nice, but not mature yet, let's wait it grows up a little". I doubt it'll grow quickly on its own, it just needs some help from all these coders who *will* use it in a few months/years !
Believe me, once you've switched to svn, it just looks life is *so* easier. Try it, it won't bite, and you'll most likely love it !
theefer