Today I have been furthering the cause by having a play with Subversion. Initial feelings are favourable, with a few caveats.
I'm going to handwave over the build process for now, it was a little involved but this is pre-release code. I reckon I could install a new repository from scratch in about half an hour now, and that's mostly compile time.
Here's an overview of things I've found important
svn diff is an offline operation.
svn diff and a few other features work offline it keeps lots more metadata is working directory compared to CVS. Almost 3 times the size of the files alone. I personally think it's worth it, as it allows more hacking to happen offline.
svn import and svn checkout seem to take a while, but updates and commits seem quicker than networked CVS.
Re:svn
richardc on 2002-04-23T15:36:36
I also liked the look of archCool, I'll take a look and see if it copes with lots of perl sources next.
My biggest issue though with arch is that the use of shell scripts kind of ties it to unix platforms (or cygwin, but that doesn't count).
Well legend[0] has it that CVS was once just a collection of scripts around RCS which later got rewritten as an application. Since there's already a rewrite afoot there's nothing explictily stopping this happening to arch, apart from maybe the all-crushing popularity of CVS.
What I'm really interested to know about svn is how long it will take for supplemental tools to catch up. By that I mean things like cervisia, WinCVS, etc.
Well there's already a win32 svn commandline client, so all the libraries build. There's still a small matter of the desire needed for some one to build it.
Both arch and Subversion have a long way to go before they begin to challenge the dominance of CVS, if only because people will stay with their familiar tools until given a compelling reason to migrate. For me it's changesets and good branch management, but I'd suspect many CVS users wouldn't know a changeset if it jumped up and down.
[0] Because I can't find a handy cite.
Re:svn
autarch on 2002-04-23T16:47:54
Between changesets and decent branching, I plan to jump ship to Subversion as soon as humanly possible.
I'd love to try BitKeeper, but I try to be a stickler for actual freedom in software licenses so I've been ignoring it, despite the fact that it seems more sophisticated than anything else out there.
arch scares me, precisely cause it's a giant collection of shell scripts.Re:svn
jdavidb on 2002-04-23T17:02:11
I've been watching subversion since it was only a few months old. (The worst thing in the world was tigris.org screwed up the mailing list archives where you can't read recent messages conveniently. I won't subscribe -- I've been subscribed to a firehose (P6) before.) Just as soon as 1.0 is out, I'm there.
Arch is new to me. I like the principle, and it's got one killer feature (IMO) subversion is putting off until 1.x: distributed branches. i.e., if the Perl 6 source code is in a repository I can create a private branch in my own repository which will treat the official repository as the trunk, and done (hopefully) in such a way that if the official repository some day decides to import my branch it can be done seamlessly.
I've got the same license qualms as you about bk. I still use proprietary software, but I don't see the need to add much more of it to what I have. MacOSX someday, and a couple of games, but that's it. Everything else I want libre, or not at all. I'm one of those bad guys who's a little peeved the flagship of free software, the Linux kernel, is using a proprietary source management system. I've read everything the author has to say on the subject, and I can't be reasoned with.
:) I'm not too scared of the shell scripts, because I don't expect that to be permanent. I wouldn't move to it before it's ported out of sh, though. The perl port Matt mentioned sounds hopeful.
All in all, I prefer subversion because its stated goal is to supercede CVS. I already think like CVS, and don't really want to have to change my thinking too fundamentally. hysterical reasons and all, you know. BTW, Karl Fogel, author of the Coriolis CVS book (a must have for your library, until subversion takes over), is one of the primary subversion authors.
bk not good enough for Linux
jdavidb on 2002-04-23T17:08:35
No sooner do I post this than I find out that Linux can't use bk patches. Chortle.
Re:svn
autarch on 2002-04-23T17:40:29
Yeah, I too think that using BK for the Linux tree is lame. Not much I can do about it since I'm not Linus. Linus is simply one in a long line of technically astute geeks who seems to think that politics are something separate from what they do, despite the fact that it gets shoved in our faces every day (DMCA!) that this is not true.
A Perl port of arch would be encouraging.
I like that Subversion is just CVS++ as well, since that's pretty much all I've used except for a brief period of using RCS (ARGH!).Re:svn
jdavidb on 2002-04-23T18:21:07
Don't knock RCS too much. It was great in its day. I've still got a few things lying around in it; I actually touched one of them this morning. You know, I actually have the O'Reilly RCS book, and it is one of my favorites.
I think RCS was used as the basis for some commercial tools, too. Sometimes it shows.
Re:svn
Matts on 2002-04-23T21:41:55
The biggest thing I think arch has going against it is its use of ftp as the wire protocol. If they'd have used sftp I'd be much more interested. Though perhaps that's just a matter of changing a few lines in the shell scripts;-) FTP
jdavidb on 2002-04-24T13:44:00
Erk! I think I knew that in the past, but had forgotten. We might as well just use Expect, telnet, and uuencode. We might as well just post all of our passwords here for public view.
Why is the world so quick to jump all over "security holes" in operating systems, but so slow to throw out these ancient, broken, insecure protocols?