Interview with Tom Lord of Arch Revision System

comforteagle writes "Every revision control system has its supporters and detractors, but none is as polar as Arch. Either you hate it or think it is the best thing in revision control ever. Built more around what our beloved kernel hackers use (BK), Arch is definitely a departure from CVS and Subversion. I've interviewed Tom Lord, Arch's daddy, about the application, and he has some -ahem- interesting answers and opinions."

Comments

I don't like CVS, Subversion, or Arch

[Anonymous Coward]

I'd love to have a Free, lightweight, distributed, reliable, easy to use revision control system.

CVS is Free and lightweight. I run it on my handheld with no problems.

Subversion is Free, reliable (so far), and very easy to use. In fact the stripped-down CVS-based CLI interface is just slightly different than CVS but much more productive.

Arch is all of the above.. EXCEPT easy to use. Here's the "eye-opener" that Mr. Lord really needs to address:

% svn --help | grep '^ ' | wc -l
28

% tla help | grep ' : ' | wc -l
105

I'm sorry but just watching that scroll by is enough to make me say "well, maybe I'll figure this out later". Which is what I do every time I look at Arch.

What I would like is a RCS that has the ease of use of Subversion, but uses changesets like Arch, and uses a lightweight storage system like Arch. I totally agree with his complaints about Subversion.. it is a bloated toy (using Berkeley DB for versioned tree storage is just the most bizarre decision). But the interface is the best, hands-down...

So.. where's the killer open source RCS?? Open source is supposed to be about good no-frills development tools!

All that and he doesn't explain...

[omaha]

I use subversion and have been on the lists for a couple of years now. Tom Lord has been to those lists as well. In all those times, including this one, he has never explained how arch is better. For the lead developer to be unable to communicate the rasion d'etre for a project in a way that makes others curious is not a good thing.

Primarily, he has only flamed svn. Even this interview he talked more about svn than arch. Nothing he said raised any interest in me to look at arch.

Also, his criticism of svn's current backend was true 8 months ago. There is another backend that will be available soon. And with that, the sytem will be able to handle additonal backends in good form.

SVK, which Lord mentioned, is a feather in svn's hat since it uses subversion as a base. If distributed mode is a real need I would suggest looking at BK or svk.

Re:All that and he doesn't explain...

[omaha]

I agree that this won't be settled here, but I do maintain that now a second backend has been accepted in to the mainline it will be far simpler to intergate other backends now. And with that, I expect to see more backends become available. Primarily due to the fact that the developers are more acutely aware of predispositions that would affect the ability of svn to integrate with "other" backends.

As to the merge capabilities, I agree there is room for improvement. However, I believe that developers/project managers are more comfortable with evolutionary change as opposed to revolutionary. In that light, I predict that svn has a bright future.

svn already has a number of front ends HTTP, SVN:// and webdav. And now, mulitple backends. It is this decoupling that will allow svn to go where cvs could not.

I in no way have any ill-will twoards T. Lord. I would only suggest that he focus on the positive aspects of arch instead of the current ego battle with other version control systems. This is one area where the best will be used. Seasoned Developers/Project managers care about this subject. If a solution is truly head and shoulders above the rest it will be recognized and used.

Re:All that and he doesn't explain...

[SpootFinallyRegister]

this interview contribures nothing. almost all of his comments about subversion seem to be of the "you suck!" variety; plenty of emotion, not much fact. on the points he did make:

Subversion requires a fairly heavyweight server

i run a subversion repository on a FreeBSD system with a Duron 600 and 128Mb of memory, and the upstream link is only 128kbps dsl. subversion runs as smooth as silk, locally and remotely. i do not consider this to be a heavyweight server.

The implementation is too complicated, the use of BDB as the primary back end creates admin hassles... managing database log files and backups

somewhat true. i dont like the fact that subversion is currently tightly bound to BDB and Apache, but this is purely behind the scenes -- subversion's implementation can (and i imagine will) be evolved to support many backends, and issues with BDB are just issues with BDB. i dont think its fair to expect subversion to be fully open and support all sorts of databases and file systems for its backend at 1.06. furthermore, evolution of the implementation can be done so that old repositories still work fine with a new version, the new version has the option to use a dfferent backend, and most importantly, there will be absolutely no difference for user whatsoever.

having to run a recovery process or worse on the server whenever it fail

recovering a corrupted database of filesystem is never fun. nobody looks forward to running fsck. however, Lord makes this sound like a common operation for whenever something fails -- clearly, he has never typed the words svn help cleanup. when user operations go bad, it doesnt corrupt the repository, and recovery isnt necessary. any problems created by an interrupted operation affect only the working copy, and can be fixed with a simple svn cleanup.

the poor merging support

Lord references the poor merging support a few times, but fails to actually detail a complaint. branching as a copy is just a clean intuitive manner to visualize a new branch off of the current line, and one that works with his precious named identifiers instead of version numbers as well. the merging is a little different than cvs, but is as good at worst. if Lord can go off on "Arch is great (you just have to learn all about it and configure your environment in just the right way)", i would think he would leave some leeway for subversion requiring a user to have at least a general birds eye view of its operation.

overall, this interview is like a political campaign that only attacks. i do not see any arguments in the text of "arch is better in this area because...", i only see "XXX is bad for the other guys." i've always taken the same view of these campaigns: if he had substance to support his product, he would have given it to us.

and in finale, he uses the final paragraph to make excuses for arch having most of the same shortcomings he lists for other revision control systems.

in all honesty, i am not familiar with arch. if arch does things better than subversion, i would love to hear it; and i am not claiming here that subversion is better. i can't, since i dont know arch. Lord would have been wise to use this interview as a forum to tell us about arch, and tell us why its good, but he didnt, and he has unfortunately turn my view on arch from neutral to maybe a little negative by virtue of jerkitude.

i take one overall feeling from this interview, due to its lack of content and vitriolic but often uninformed attacks. Tom Lord, who are you trying to fool?

Re:Where are the screenshots?

[Alioth]

No. The 'commandline POS' is very necessary - it's what runs underneath. I have no experience of Arch, but I do use Subversion - and if you want to use the GUI (say, on Windows) you use something like TortoiseSVN which integrates with Windows Explorer. However, advanced users may want to script some of their Subversion commands, or possibly just find it faster to use the command line than a GUI. Personally, I find Subversion pretty easy to use on the command line so I don't bother with a GUI - it gets in the way. I'm using Mac OSX right now - the epitome of a nice GUI, and whilst I use OSX's superb GUI for many things when it comes to my version control tools, I forgo the pretty GUI and just open a Terminal.

The main problemw ith a GUI is that you can't script them (or not trivially anyway). A development tool (which is largely what version control is) that cannot be scripted is useless. The GUI is not the be-all-and-end-all. This is what frustrates me so much about Windows on the server (and why it's not a very good server OS) - it's because many parts of Windows are totally unscriptable out of the box. Don't do this to our version control software too.

The GUI should be separate from the 'business logic' of any tool in any case - therefore there's absolutely nothing wrong with a GUI that drives command line tools underneath, or perhaps provides another interface by linking to a library which provides the heavy lifting parts of the code.

Re:No people skills.

[tlord]

> You fail to realize that Tom Lord is a genius,
> and as such has no need for people skills.

I only wish....

Re:I'm left out...

[sketerpot]

It stops many, but you don't see them. In other words, you're mistakenly drawing conclusions from a skewed sample.

I want to thank the Subversion team

[MemoryDragon]

Although this is an Arch thread, after these rantings by Tom Lord (geeze does he really need to bash other projects without any serious explanation every time he gives an interview) For the wonderful CVS replacement they made. I used SVN for half a year in my last job, and the thing never gave me any serious trouble. From the day it reached 1.0 there was at least a basic integration support there, and the mailing lists are well moderated. Thanks Subversion team for the excellent program you delivered, you dont deserve Tom Lords constant bashing. But back to Arch, everybody knows it is a good program, all it needs is better tool integration. The problem has been existing for years.

Does he know ANYTHING about Subversion?

[glwtta]

Incrementally better naming scheme for revisions and branches? I am not sure if he means the per-file vs. per-repository revision numbers, or their tagging and branching systems, but either way the two have nothing in common. It just doesn't get more "non-incremental" than going from CVS's file tagging to svn's copy-to-branch/tag mechanism.

The BDB backend has it's problems (though none of them nearly as drastic as he seems to think), but has he really never heard of the FSFS backend?

The rest of the criticism is so vague that it kinda makes it hard to reply to: "it takes too many steps backward in various areas", oh, "various areas" - of course! I've been noticing that.

I'm in the process of moving to Subversion from CVS (which I agree is deeply broken, by todays standards), and I've yet to encounter a single thing that Subversion is worse at than CVS. And a hell of a lot of things that it does much, much better.

Now if that interview presented the tiniest bit of information about what arch does differently (apart from, you know, not being "teh suck") I would be tempted to check it out.

Re:I'm left out...

[MrResistor]

I used Bitkeeper for about two weeks, before being told that since I'd said this on the arch list: "I'd cringe if I had to use Bitkeeper", and because of my public pro-stance on free software (as they had researched from my homepage - http://www.souldound.net/), I was on their shitlist and they would not sell me, and therefore the company I currently work for, a license to use Bitkeeper.

Yeah, it's too bad Linus seems to be so happy with it, because Larry McVoy is a real dick. I posted something here on /. about how I don't think their "you can't develope revision control software" clause would hold up in court, and he personally flamed me (through email, of course) with all this crap about how I don't know anything and had no right to an opinion since I hadn't built a multi-million dollar company.

IMHO, the man's a complete asshat, which is really a shame, because he seems to have a good product that a lot of developers will never touch because of his childish behavior.