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."
Sorry, I'm not exactly a professional developer but:
Whats the advantage to killing the standard of CVS, that seems to work well today? I mean, are the features of this "Subversion" make it worth the switchover?
The only problem I have with subversion is its dependences on apache which just gets in the way in a local project unlike cvs which can be used over rsh/ssh, cvsserver, and locally. The other problem with apache is that they use the HEAD of httpd and apr as their base which is wrong for use with Darwin(Mac OS X). Also apache is big and is too modular for a project like subversion.
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."
aegis.sourceforge.net
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.
That's the main problem for adoption of arch, subversion or Aegis. All of these lack support for NetBeans, Eclipse and the other important IDEs.
I guess the moment one of the next generation version controls systems gets good IDE support will be the break-through for this IMHO needed technology improvement.
Bye egghat.
-- "As a human being I claim the right to be widely inconsistent", John Peel
It does if you add it (or automate adding it with a simple cvs-rename script). However, it's not clear that that matters much.
you can not check out last weeks version of it
Sure you can: if you ask for last weeks version of the software, it will contain the file under the old name. If you ask (somehow) for the individual file, CVS will tell you that it didn't exist at that time, which is correct and consistent. It would be inconsistent if I got a week old version of "newname.c" if "newname.c" didn't exist at that time. I do hope Subversion doesn't do that.
and it is not included in diffs of changes that spanned multiple files.
Huh? Of course, it's included. The diffs will contain a deletion for the old file and an addition for the new file. That is exactly what should happen. I don't think "diff" even supports any other way of renaming.
Deleting and adding, though it may be well-defined, is also a really ugly and non-intuitive way of doing it.
Well, your message suggests to me that handling renaming any other way than the way CVS does may actually be worse.
For instance, when I set up my project a few months ago, I did look at other code control systems, but CVS won because everybody had it practically installed by default, and it was good enough. Considering how many different commands there are to do very similar operations in arch, it'd be better for you to give it a proper intro methinks. The Linux Journal article just left me with questions.
Aegis sounds like a nice system, but it doesn't even run on Windows, nor did it ever run on Mac OS 8/9. CVS runs on everything, and Subversion is designed to be extremely portable, too. Sorry, but that's a critical requirement of a lot of developers - even open-source developers, because lots of us want our open-source programs running on as many platforms as possible.
> [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.)