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."
If you're interested in clients, check out the http://scm.tigris.org/ pages: There's a GTK and a cross-platform GUI in the works (And I've seen a few other GUIs on elsewhere (sourceforge?)
"Can of worms? The can is open... the worms are everywhere."
I really hope that building ancillary tools like nice clients (wincvs) and useful add-ons (bonsai) is easy enough to do, because that's really where the critical mass is wrt widespread adoption.
Most of the subversion functionality is actually in a library, which makes it a lot easier and more robust to build gui clients and such for subversion. CVS, by comparison, is only accessed through the command-line client, so cvs gui clients have to execute the cvs binary and then parse the output, which as you certainly can imagine, is cumbersome.
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.
It's been years since we have had any signficant problems with CVS; it seems to be just ticking along, doing its thing. So, I'm not convinced switching to subversion would be enough an advantage to outweigh the risks and retraining costs associated with it. I think it would take a number of large and very visible open source development projects switching to Subversion to give me enough confidence in it to try it.
> [arch isn't portable beyond unixen because
> it's largely written in sh]
Just as a small clarification on a technical issue:
1) In some sense, yes, that's an obstacle.
2) It is very portable among solid Posix and nearly-Posix systems. It's not terribly useful as it stands on cygwin because (I've been told) `fork/exec' is very slow on cygwin.
3) Most importantly, though, and a bit unlike SVN, arch is designed to be implemented more than once. It's tiny enough to rewrite (say, in Python or Perl) in just a few man-months. It's based in part on the idea of standardizing repository formats, exchange formats, and so forth. In other words, from the point of view of whether or not to support finishing arch, you have to regard it not just as a particular implementation, but as a collection of standards that are effective, simple, and cheap and easy to (re)implement in many different contexts. It's a bit like designing a cataloging system for libraries -- you think bigger than just one implementation.
(Regarding other comments in this "thread", about "get a job", or "you're just trying to steal funding from svn", etc. Well, those aren't bad advice/concerns/objections to discuss -- but I don't think the blog format really supports that kind of discussion -- so I'm going to let them go without direct reply.)