Slashdot Mirror
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."
I don't know anything about Mr. Lord's product, but I do know he sounds like a 12 year old boy when he writes. People might respect you and your work more if you use the word "blows" a little less, and spend less time lashing out at other products with such ferocity.
My sig is blank, I typed this by hand.
Is this a CVS problem or a NFS problem?
Either way, the solution is "don't run CVS over NFS". Use the client-server protocal - either ext or pserver.
The Army reading list
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!
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.
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.
Oolite: Elite-like game. For Mac, Linux and Windows
He's hampered more by the blind faith of other people in their own way of doing things, and their unwillingness to listen to anything new.
> You fail to realize that Tom Lord is a genius,
> and as such has no need for people skills.
I only wish....
It stops many, but you don't see them. In other words, you're mistakenly drawing conclusions from a skewed sample.
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.
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.
sic transit gloria mundi
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.
/. 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.
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
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.
Under capitalism man exploits man. Under communism it's the other way around.
The main problemw ith a GUI is that you can't script them (or not trivially anyway).
Okay, this is a pet peve of mine and (surprise) it does relate to arch, subversion, et al. The problems Tom Lord mentions are found everywhere in open source, and that is why X.org, arch and other 'duplicative works' or 'hateful forkings' exist.
It is very trivial to script a properly built GUI. Now the deifintion of a 'properly built GUI' goes beyond being able to be scripted, but does include this feature.
How? Why? From HCI and study of disability access we know that every action possible in a GUI should be performable with out a mouse. On Microsoft Certified Software this usually means everything has a contextually unique hotkey.
Windows 3.1 included a nifty tool called Recorder. Recorder is a lot like UNIX typescript, i.e. type 'script' and it records all the stuff in your command line session until ^D, except it only recorded your inputs to the computer. ALL GUI. No Terminal. Using the run box and keyboard (hot-key) only commands you could record a fairly portable script to automate your task. Given that the script (macro) was in textual format (IIRC) basic text editing skill was all you needed to turn a simple script into whatever you wanted (including being driven by command line scripts.)
The utter lack of standards compliance in Linux GUIs contrasts with the impresively standards-compliant command line applications (that are often definitive or reference implementations.) Let alone the lack of support for something like uniform contextual keyboard hot-keys.
A GUI for arch or CVS or subversion could be made with scripting in mind. And not just via embedding LUA or another 'lighweight' language. However, proper GUI scripting would take a project on the order of the Ximian Desktop to make it work even as well as a cheesy under-utilized program from 1980's Microsoft.
(Oh, and scripted GUI + decent version control GUI + automation tool = 100% developer envrionment matched automated test setup. Which can potentially be very cool if a bug is due to how a naughty newbie code monkey setup his little development cage. It's happened. And I've had to clean that monkey's cage one time too many.)
-----
Ugh. That's two pointless rants in one day. I need caffine.
"You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
How is this model any different than the history of Linux kernel development? The packet filter portion of Linux comes to mind immediately.
It's not always a bad thing to strive toward production ready code. It can be a good and necessary counterbalance to the "think forever" reflex that takes hold in projects that go too far in the other direction.
Concerning the tone of the interview, I wouldn't be at all surprised that the best source-code revision system comes from a Theo-like development camp. Some projects can handle a "let's all get along and not say anything too combative" and some projects do much better at the other extreme.
Personally, I'll download my firewall, my filesystem, and my source control system from the crabbiest ubertard I can find.
Why there are CVS systems? CVS systems exist in order to coordinate source code sharing between multiple people. In other words, CVSs are information management mechanisms.
Why can't we see that CVS is just another version of the solution for the same problem? that problem is distributed information management. There are numerous places that this problem pops up: distributed filesystems, distributed databases, e-mails sharing between applications, source code sharing, etc.
It should be the role of the operating system to provide distributed information management. It would render a whole class of applications unneccessary and it would make programming much easier.
It is a great chance for open source software to provide this solution at open source level and gain a great technological, economical and social lead over propriatery software.
David Roundy, main developer of darcs, is very much a non-asshat.
For vanilla C code clearmake is great. But you have to do a major amount of hacking to get the Sun C++ compiler's template repository to work with ClearCase. Ditto for Java and its class files. The Clearmake model of one source file per object file breaks down when the compiled source files create more than one resultant file under certain conditions.
In my view, the biggest barrier to adoption of new source code control systems is the confidence level. CVS suffers from lots of problems, but they are well understood due to the age of the system. Similarly I only trust Clearcase for my commerical development as it has been around so long (although BK is progressing well with gathering a bigger user base)
For any new system to be a contender it needs to have either a large existing user base (chicken and egg problem) or a very comprehensive test suite with code and problem domain coverage figures. If I am going to trust my (assumed valuable) source code to an SCM system, then I need to know that it behaves correctly. DARCS scores lots of points for being based on a semi-formal proof of correctness, but that only proves the algorithms not the implementation.
I've discussed this on Shlomi Fish's mailing list "Better SCM", but the real opportunity for all of the open source SCM projects is to collaborate on collating normal and pathalogical examples of SCM problems and building a common test suite.
Asmo