Forgot your password?
typodupeerror
Programming Technology

Interview with Tom Lord of Arch Revision System 334

Posted by michael
from the call-him-lord dept.
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."
This discussion has been archived. No new comments can be posted.

Interview with Tom Lord of Arch Revision System

Comments Filter:
  • by Three Headed Man (765841) <dieter_chen@NosPam.yahoo.com> on Friday September 24, 2004 @04:45PM (#10344099)
    "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."

    They forget those of us who have never heard of it before.
    • Re:I'm left out... (Score:5, Interesting)

      by Curtman (556920) on Friday September 24, 2004 @04:49PM (#10344135)
      They forget those of us who have never heard of it before.

      And those of us who have heard of it, but have no idea if its a good thing or not.

      I noticed freedesktop.org has started using it to some degree [freedesktop.org]. But like I say, I have no idea if thats a good thing. It is slightly inconvenient in that I have to go read yet some more docs to use it. :(
      • I noticed freedesktop.org has started using it to some degree.

        That's interesting, because I remember them saying at OLS that they were considering it, but wanted to audit the code and the design a bit first. Based on your comment, I assume they've actually done the audit and decided they were happy with it--does anyone have a pointer to the results? I'm sure I'd be not alone in being interested.

        --Bruce Fields

      • Re:I'm left out... (Score:5, Informative)

        by Humble Legend (254888) on Friday September 24, 2004 @07:08PM (#10345183) Homepage
        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.

        Needless to say, I found this a little confronting, took stock of my temporary moral slip in even considering the use of proprietary software (forgive me Free Software gods), and promptly got stuck into arch/tla, which I've now been using for about a month.

        In my experience, tla is more flexible - the design really does reach high, although the learning curve (at the moment at least) is a little higher for sure - you really do have to go read the tutorial, wiki, etc. I found the people on the gnu-arch-users@gnu.org mailing list to be very helpful though - even if personal/ power tiffs were going on, those involved never ceased to be supportive in replying to my questions.

        Hope that's a useful datapoint,
        Zenaan
        • Re:I'm left out... (Score:5, Insightful)

          by MrResistor (120588) <`peterahoff' `at' `gmail.com'> on Friday September 24, 2004 @08:21PM (#10345583) Homepage
          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.

          • by Anonymous Coward on Saturday September 25, 2004 @04:09AM (#10347144)
            What is it with version control and asshats? It's like they're attracted to each other or something. I doubt anyone would deny McVoy is an asshat, and Tom Lord certainly hasn't seen daylight in years do to his choice in rectal headwear. The SVN devlopers can be asshats from time to time. I'm not sure if the CVS authors are asshats, but they're probably dead by now anyway. A ClearCase developer punched a baby once (in his defense, the baby was being kind of a dick).

            I rest my case. Version control makes asshats out of people.
        • by pnot (96038)
          because of my public pro-stance on free software... I was on their shitlist and they would not sell me, and therefore the company I currently work for, a license to use Bitkeeper.

          Holy hell. That's not so much unprofessional as infantile. Let's hope Linus never pisses Larry McVoy off...

          Linus: "Hey, that's a pretty nasty-ass [redmeat.com] shirt you're wearing!"
          Larry: "Yeah? Well, in that case I revoke your BitKeeper licence! How d'ya like them apples? [playgroundlaw.com]
    • by themassiah (80330) <scooper@coopster.net> on Friday September 24, 2004 @04:52PM (#10344172) Homepage Journal
      Since when has being completely uninformed stopped any Slashdot readers from making informed opinions and spreading them around?

      You must be new here.
  • by Anonymous Coward on Friday September 24, 2004 @04:45PM (#10344100)
    Interview with Tom, Lord of Arch Revision System
  • by Anonymous Coward on Friday September 24, 2004 @04:50PM (#10344145)
    # cd /usr/src
    # export CVSROOT=:pserver:anoncvs@cvs.gnuarch.org:/usr/cvsr oot
    # cvs login - the password is anoncvs.
    # cvs checkout arch
  • Tact? (Score:5, Funny)

    by keiferb (267153) on Friday September 24, 2004 @04:51PM (#10344154) Homepage
    This guy should go into politics! His brain-mouth cable has no filter on it. It'd be nice to hear politicians describe their colleagues' bills as "a horrible, horrible design based on a few very good ideas" or "clunky junk".

    I'd love to hear his opinion on the vi/emacs debate... that'd get some heads rollin'!
    • I disagree... (Score:5, Interesting)

      by CaptainPinko (753849) on Friday September 24, 2004 @05:12PM (#10344348)
      don't we get enough marketing droids that can't ever say what they mean? I agree he was upfront, blunt, and brutal but in the end he didn't seem crazy or wild or unreasonable. He even backed up some of his more inflammatory statements. I think he was a very good interviewee. He did seem to be a little too forgiving to his project own weaknesses but that's is not unexpected and relatively forgiveable.
    • Re:Tact? (Score:3, Interesting)

      by Vellmont (569020)
      I dunno, the best software I've seen has come out of derision of bad software. I don't think the creator of Postfix loved sendmail too much. Many people dislike BIND and have come out with arguably better alternatives.

      The other extreme is just developers who hate the popular software just for the sake of hating popularity. That seems to be the case with DSpam over Spamassassin. I don't think that's the case here however. While CVS is reliable software and people know how to work around its flaws (and t
    • by js7a (579872) <james@b[ ]k.org ['ovi' in gap]> on Friday September 24, 2004 @11:21PM (#10346303) Homepage Journal
      I have a huge amount of respect for him. He taught me that compromise is way overvalued.
  • Design and License (Score:2, Interesting)

    by Anonymous Coward
    Well, he slams the subversion design pretty good. I don't know anything about the design of subversion of either Arch or Subversion to comment on either - maybe someone else can, but subversion seems to be gaining quite a following from what I've seen.

    Look at the way the Linux kernel project works, at least for developers who are willing to drink the koolaid of Bit Keeper (BK) licensing.

    I guess that's a different koolaid than what the Stallman/Gnu cult members are drinking.
  • 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.
  • 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.
  • by Anonymous Coward on Friday September 24, 2004 @04:54PM (#10344192)
    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!
    • Here's a couple to have a look at:

      PRCS [sf.net]
      Superversion [sf.net]

      Of the two I use PRCS all the time for production code. Superversion's still a very new project but I think it shows a lot of promise, and well worth a periodic look.

    • by Anonymous Coward
      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.

      And of course is decentralised like arch.

      Darcs [abridgegame.org]

      Darcs wiki [scannedinavian.org]

      Getting started with darcs in 5 steps [scannedinavian.org]

    • I think CVS is the best of a pretty poor bunch at the moment - it may not be flashy, but it works. Subversion looks nice, and is mostly a better cvs, but it seemed to be a touch flaky with large (>1Gb) trees when I last tried it (getting itself into a corrupt state). It also used to let you check in files with bad filenames and then protest when you tried to check out. And lots of little things are essentially undocumented so you're forced to rely on the mailing list too much. I'm not thrilled about aspe
      • I use Subversion at work with a large (half-gig) source tree, and primarily on Windows (with TortoiseSVN). We use the new FSFS backend. Seems to do quite well, even on a networked filesystem.
      • by Anonymous Coward
        "I think CVS is the best of a pretty poor bunch at the moment - it may not be flashy, but it works. Subversion looks nice, and is mostly a better cvs, but it seemed to be a touch flaky with large (>1Gb) trees when I last tried it (getting itself into a corrupt state). It also used to let you check in files with bad filenames and then protest when you tried to check out. And lots of little things are essentially undocumented so you're forced to rely on the mailing list too much. I'm not thrilled about asp
    • svk is an attempt to use the svn backend to implement a changeset-oriented distributed revision control system.
    • by mrdlinux (132182) on Friday September 24, 2004 @05:46PM (#10344617)
      You want Darcs. http://abridgegame.org/darcs/ [abridgegame.org].

      Using it is as simple as:

      darcs init <dir>

      .. hack hack ..

      darcs add <file>
      darcs record

      .. interactive questions about changes ..

      Then you have the option of sending your changes to other repositories, since Darcs is distributed.
      You can copy/upload them directly, pull them from the other side, or even email them.
    • by iabervon (1971) on Friday September 24, 2004 @06:13PM (#10344824) Homepage Journal
      The article says that Tom Lord claims that a comprehensible interface for arch should be ready by the end of the year. Arch really is the right design, and will be ideal once there's a sane interface.
  • GNU arch when an OSA (Score:3, Interesting)

    by JohnGrahamCumming (684871) * <<slashdot> <at> <jgc.org>> on Friday September 24, 2004 @04:55PM (#10344196) Homepage Journal
    GNU arch was awarded [opensource.org] an Open Source Award last quarter.

    As ever people OSI is accepting [opensource.org] nominations for OSAs.

    John.
  • Most polar? (Score:3, Interesting)

    by Sean Starkey (4594) * on Friday September 24, 2004 @04:55PM (#10344198) Homepage
    I think the most polar source control system is Rational's ClearCase. You really love it or really hate. It's a very complex software package, but very powerful.

    Personally, I really like ClearCase. Too bad its so expensive, otherwise I'd use it for all my open source work.
    • Re:Most polar? (Score:5, Interesting)

      by wintermute42 (710554) on Friday September 24, 2004 @05:06PM (#10344302) Homepage

      Cost issues aside, I think that perception of ClearCase is effected by whether you have to set ClearCase up yourself or not.

      The first time I used ClearCase I had to set up the ClearCase environment. I did not like the ClearCase documentation much. Rather that just telling you what you need to know to get the system set up they provide their grand vision of the world. I could care less about their grand vision, I want to get the source control system working. After this experience I was not a big fan of ClearCase.

      I used ClearCase again in an environment where the release engineering group managed ClearCase, along with the releases. They would "freeze" the branches for release (and let you in when you had a bug fix). They would also create new development branches and they managed the main line branch. In this environment ClearCase was really nice. I liked it a lot and prefer it over CVS.

      In summary I'd say that ClearCase is a higher cost source control system. You not only have to pay for the software license for ClearCase but part of someone's time to manage it as well. For small projects and software development groups this does not make sense. But once a group reaches a certain size, the cost can be justified and ClearCase is nice.

      I am currently working on a project where there there is a core set of software that is used by three different groups, each of which will probably want their own changes. In this environment I think that a release engineering group and ClearCase would be justified (of course that does not mean that we're going to get a relase engineering group and ClearCase).

      • Re:Most polar? (Score:3, Interesting)

        by bheading (467684)
        Clearcase, when you couple it with the UCM product and Multisite, unlimited budget, and big machines to run it on along with a dedicated crew, is an outstanding product and it's impossible to beat. You basically can't get anything better. The trouble is that it's extremely, extremely expensive (in $$$ terms) and requires big-ass hardware, and it falls to bits when you've got developers who are on the road a lot (snapshot views just don't hack it, and to support them properly you have to eliminate all relian
    • Clearcase is an overbloated, expensive pig of an RCS.

      Now, that's not to say that I haven't appreciated Multisite, or some of the hairier things I could do merge/branch-wise with Clearcase, so it's a clever pig, but overbloated and expensive nevertheless.

      • Yes, but the grandparent is basically saying "if you don't have to pay for it or install/administer it" (something called "being a user" in the commercial software world) then it's pretty good - and i tend to agree with him. Ten minutes of googling will have you doing most of your day to day stuff just as well in cleartool as you did in cvs, and after that the sky's the limit for the overwhelming majority of developers. The (very) few things you can't do in cleartool (like not treating checkedout as a find
    • Don't know about that... You ever use Perforce?
    • Having used CC, it has a lot of problems. At work, we have 1 division that uses it that needs to share code with mine which doesn't. 90% of our ideas for processes and build ideas were shot down because "its too hard to do it in ClearCase". For our RCS system, we have 1 guy admin it part time. For theres, they need a full time admin.

      Oh, lets not forget that WIndows clients were unable to talk to Unix vobs, and vice versa. And lets not get into the bloated, bandwidth eating, utterly useless pig that is
  • Glad to see.... (Score:5, Informative)

    by GillBates0 (664202) on Friday September 24, 2004 @04:59PM (#10344226) Homepage Journal
    Support Services (coming soon...)
    * Per Incident
    * Subscription
    * Deployment Services
    * Custom Development

    that they're considering starting Support services soon. As a Configuration Management guy at a fairly large company, one of the reasons major corporations choose commercial version control software (Rational ClearCase, etc) over the open source counterparts (CVS, etc) is primarily due to lack of formal support.

    I'm all for open source and even dislike it when companies reject Linux because of "lack of support" (this is ofcourse changing with RedHat's efforts), but experience has taught me that not everybody in a large organization is a hacker and willing to figure out the intricacies incase something goes wrong. They'd rather pay for a service contract incase anything goes wrong.

    And ofcourse, there's also the accountability angle (which I dislike) to it, when you're using the version control software to develop critical/huge amount of bread-and-butter software - companies want to be able to have someone to point fingers at incase something messes up.

  • CVS Clunky? (Score:3, Funny)

    by Anonymous Coward on Friday September 24, 2004 @04:59PM (#10344228)

    How can he say CVS is clunky junk?

    I use it on my 486 SCO Unix machine and think it's the cat's meow.

  • by omaha (41554) on Friday September 24, 2004 @05:03PM (#10344271) Homepage
    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.

    • by omaha (41554) on Friday September 24, 2004 @05:21PM (#10344412) Homepage
      As to svn backends... I think it is prudent to point out a false statement made by Lord.

      from: http://web.mit.edu/ghudson/info/fsfs/ [mit.edu]

      "FSFS" is the name of a Subversion filesystem implementation, an
      alternative to the original Berkeley DB-based implementation. See
      http://subversion.tigris.org/ [tigris.org] for information about Subversion. This
      is a propaganda document for FSFS, to help people determine if they
      should be interested in using it instead of the BDB filesystem.

      and from http://subversion.tigris.org/svn_1.1_releasenotes. html [tigris.org]
      "Non-database repositories

      It's now possible to create repositories that don't use a BerkeleyDB database. Instead, these new repositories store data in the ordinary filesystem. Because Subversion developers often refer to the repository as "The Filesystem", we have adopted the rather confusing habit of referring to these new repositories as "fsfs" repositories... that is, a Filesystem implementation that uses the OS filesystem to store data."
      • by tlord (703093) on Friday September 24, 2004 @05:27PM (#10344464)
        > As to svn backends... I think it is prudent to
        > point out a false statement made by Lord.
        > [Hey, FSFS exists.]

        I agree it is good to point out FSFS. The
        interview is, indeed, misleading in that
        respect.

        As far as I know, back when the interview was
        conducted, FSFS did not exist or at least was
        not on many radars.

        A separate question is whether or not FSFS
        really makes the server-side of svn all nice
        now or not --- but certainly that is not going
        to be worked out in /. comments.

        -t
        • 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/pro
        • by belroth (103586) on Friday September 24, 2004 @06:27PM (#10344911)
          One major advantage in using fsfs over bdb with Subversion is that you can use a network share for your repository now, this was not a good idea before but now it works.(1.1 is still in beta though)
          FYI you can also use Apache or subversions own server to host a network repository.

          If you want a windows gui front end for SVN try TortoiseSVN [tigris.org], this integrates nicely with explorer and works pretty well.
          I'd like a similar ability with Konqueror, but that's a long way down my to do list.
          It'd also be nice to work out how to really handle the situation with working cross platform and case(in)sensitive file names...

    • Tom Lord has been to those lists as well. In all those times, including this one, he has never explained how arch is better.

      This is exactly what turned me off from trying arch when I was looking to replace my CVS stuff with something a little less wonky. Subversion is very clear about what it does, and why it does it. When trying to find out if arch might meet my needs better, all I found were a bunch of rants by Lord about how "Subversion won't work, because it's deeply flawed, and arch is better" Whic

      • You might consider reading this then:
        http://www.gnuarch.org/arch-overview.html
        and this:
        http://www.gnuarch.org/arch-tech.html

        That tells how arch works. It would have taken too long in that interview for him to explain everything. But here is what you need to know:

        Arch is a revision control system the only tools you need is:

        * tar
        * patch
        * diff
        * diff3

        Thats it. Anything those tools can do you can do. Remember this when years down the road, arch or whatever is gone and you need to recover some old arch
    • by SpootFinallyRegister (787720) on Friday September 24, 2004 @07:26PM (#10345285)
      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?

  • Change is good... (Score:3, Informative)

    by Chuck Bucket (142633) on Friday September 24, 2004 @05:06PM (#10344300) Homepage Journal
    while my company is stuck in CVS, Subversion is not going to be too big a jump. As the build manager I'm heading up the switch, and love the similarities, and the advantages of svn. I've installed/played with ARCH, however I've never gotten very comfortable with it. While I don't think it would be very hard to learn, there's certainly a learning curve that others will have to go through.

    PCB@!
  • zero (Score:4, Informative)

    by Anonymous Coward on Friday September 24, 2004 @05:08PM (#10344316)
    arch tutorial [gnu.org]
  • by legLess (127550) on Friday September 24, 2004 @05:10PM (#10344331) Journal
    Tom Lord sounds like he got his argumentation skills by watching Beavis and Butthead, reading JeffK [slashdot.org], and getting into flame wars with trolls on /.

    Q: What's wrong with Subversion?
    A: It sucks.
    Q: What's wrong with CVS?
    A: It sucks.
    Q: Can you be more specific about Subversion?
    A: Yes. Subversion is teh suck. I realize that's a little inflamatory, so let me say that the sky is blue, dogs are hairy, and Subversion is TEH SUCK, fagg0t!!11
    Q: Can you be more specific about CVS?
    A: Yes, allow me to be more specific. It sux0rs. Hard. CVS is teh sux0r.
    Q: What's good about Arch?
    A: It rules. Also, I have a large penis. Fagg0t.
    • OMG!

      This actually convinced me to read the linked article.

      I'm not even half way through and I'm already laughing!
    • I really, really wanted to try 'arch' but failed. I was up and productive with Subversion in about 20 minutes. The very clear and comprehensive PDF book on Svn has been well-used.

      The last straw for me was Mr. Lord's attacks on Subversion, which seemed unhelpful to say the least; wheras the cogent response by Mr. Greg Hudson was a model of respectable behavior.

      After several months of near-constant use of Subversion -- I love it, it's a joy to work with. It has a number of quibbles, but then again, dont
      • If you wanted to use Arch, but it's too complex, then you should try darcs [abridgegame.org]. It has fully-distributed operation, but you can get up and running in much less time. Commands have a closer resemblence to what you're used to in Subversion or CVS: "darcs record", "darcs revert", "darcs diff", etc.

        The best thing about darcs is that every operation is local by default. Subversion does diffs locally; darcs does everything locally. You only need to wait on the network when you want to get something not on your m
  • No people skills. (Score:5, Interesting)

    by Ectospheno (724239) on Friday September 24, 2004 @05:20PM (#10344404)
    Tom Lord has tried to work more closely with other revision control packages before (including the subversion team) but he has been hampered by his complete and total lack of people skills. I don't think he tries to, but he ends up offending everyone he tries to have a "discussion" with. Its comical and sad at the same time.
  • by Anonymous Coward
    Article summary: every decision made in the development of Subversion is an obvious mistake and a total failure - the result of naive programmers daring to disagree with the "Lord" of revision control.

    When given the chance to talk about versioning systems, he spends more time bad-mouthing the competition than
    he does promoting his own solution. Did one of the Subversion guys "steal" his girlfriend or something?
  • darcs (Score:5, Interesting)

    by The Pim (140414) on Friday September 24, 2004 @05:32PM (#10344494)
    Ok, I admit I just want to get darcs mentioned here, but I really want to know what Tom (as well as Larry McVoy) thinks about darcs [abridgegame.org]. In particular, whether the theory [abridgegame.org] will stand up to real use and scale to large projects. I have a hunch that David Roundy has discovered much of what Larry McVoy said was a dozen PhD theses worth of research [google.com] behind BitKeeper.
    • Re:darcs (Score:5, Interesting)

      by Anonymous Coward on Friday September 24, 2004 @10:20PM (#10346048)
      Hi,

      I (Larry McVoy) have looked over Darcs, Monotone, Arch, Codeville, and I think some others that I can't remember and I can easily say that no, they haven't discovered much of what we have done.

      Let's take darcs as an example. It's a cool system if you are a math or physics person. You can write proofs about how it works, much like BitKeeper. We like that and applaud anyone who is thinking that hard (and if you are looking for a job please come talk to us, we are always hiring). However, darcs suffers from the math problem. It's all about math and not at all about being pragmatic. Here's a for instance. The BitKeeper tree holding the 2.6 kernel has about 55,000 changesets. A null update using BK is 4 seconds (which is insanely slow in our opinion). Try doing the same thing with darcs and you will wait and wait and wait... That's just the first example of how it doesn't scale. The openlogging tree for linux is somewhere north of 110,000 changesets. *All* other systems die with that sort of load. We're slow but we work and we know how to fix the slow part.

      This problem space is strange, it is part math and part pragmatism. You have to do both and darcs does one of them. And it does it in only one of the areas, there are many many more. Repository synchronization, rename handling, merging, user interface, installation tools, working well on Windows as well as Unix, etc., etc.

      Our payroll is higher than any open source SCM system has generated by a factor of 50. It's higher than the reiserfs payroll, it's higher than lots of well known little companies doing useful stuff. It's high because there are lots and lots of corner cases *in addition* to the hard math stuff which needs to be done.

      Since we're talking about Arch, here's another example: we recently got a commercial customer who tried out arch on windows and came back and told us BK was at least 10x faster. And we told him that we think BK is way too slow on Windows. He liked that. The point being is that it isn't just about architecture, or licensing, or features, it's about a lot of not-so-fun stuff and that's why a commercial answer will always be better than a free answer. It costs a lot of money to solve the non-fun problems. Open source solves the fun problems (extremely well, I might add) but unless the project is very visible (i.e., the kernel) it starts to fall down when you hit the non-fun problems. Think about it - if noone is paying you money or telling that you rock while you are doing the grunt work - how long are you going to do that? Not very long, just look at 90% of the "projects" on sourceforge, all talk, no code.

      It's worth repeating that last bit. SCM is an undervalued field. Every engineer thinks that they can reproduce what BK does with a few scripts wrapped around CVS or RCS. While they may think that it flies in the face of the over 100 man years we have in BK and we know we are nowhere near good enough. The bummer is that the perception is that this stuff is easy but the reality is that it is hard. Both technically hard and detail hard. It's way more work than people think. But precisely because people don't value it, that's why the only real answer is a commercial answer. Yeah, yeah, you all love to give me crap because BK isn't GPLed but *none* of you have put in 1/10th as much effort as I have or have made 1/10th as much of a difference in this space. Talk is cheap, show me a better answer and I'll be impressed. It won't happen because it costs way way way too much money to deliver a better answer. How's the arch installer on windows? Graphical? Is it careful about not screwing up the registry? Can you have two different versions installed at the same time? What about the transport layers? Works over http? Really? Through all the wacky proxies out there? You get the idea, right?

      That's why all this discussion of arch or darcs or whatever is just nonsense. You all think this stuff is easy so you are never going to cough up the $30M or so it will take to solve it right. Sad but true. I guess it's good for us, it means we have a market, but it would be nice if you knew a bit more about the topic. I love it every time it comes up, the world is definitely becoming more aware at least.

      --lm
      • Re:darcs (Score:5, Interesting)

        by The Pim (140414) on Friday September 24, 2004 @11:16PM (#10346288)
        (Someone mod parent up--this is really Larry.)

        I agree that "darcs suffers from the math problem", at least in that the implementation has focused on getting the semantics right and not on performance. (And unfortunately, the semantics are still not all right.) David maintains a kernel tree in darcs as a reminder of all the ways it doesn't scale. However, he also thinks most of them are fixable "post 1.0", and given how smart and capable he's proven to be, I give that claim some respect. Alas, I haven't had time to learn the math well enough to really be sure.

        Regarding the economics, I don't think SCM is an undervalued field. Or at least, the free software community can find a way to value any field it needs to to make progress. (And for SCM, you're helping!) People said we didn't value desktops, or help, or installers, or web browsers, or couldn't do webdav or other protocols "at the top of the stack". "No fun" is what people have said about all of these. (And we're still not great at all these, but I think we're on a clear path to get there.)

        What does this mean for darcs? It already has good semantics, is easy to use, and has a solid theoretical foundation. I think that free software folks will increasingly value distributed SCM and it will get more development man-power (if not as much as bk). These are excellent growth factors, and I suspect darcs will be able to handle 90% of projects out there in a few years. Unless the foundation is found to be weak (which is why I asked about that). Unless David loses interest before someone else steps up. Unless, unless, unless, but I like its chances.

        Put it this way: I agree that open source does not solve things that are too hard or no fun. But the second is actually a non issue: when we need something, powerful economic and selective forces will make it fun for someone. So I really care about the first, and I'm trying to gauge whether distributed SCM is too hard for David and others attracted to darcs. I suspect that it's not too hard, at least to get to the 90% mark.

        Thanks for taking the time to reply. I do enjoy reading what you have to say.

      • Re:darcs (Score:3, Informative)

        by boots@work (17305)
        Just as a point of information: last time I tried checking the kernel tree into Darcs, simple operations took a fraction of a minute to complete. Which is fairly slow, and probably much slower than Bitkeeper, but I think not ridiculously slow. Bearing in mind that just untarring a tree takes several seconds, it's not completely unreasonable. It's OK for a product that's pre-1.0, and a few years younger than BK.

        Bitkeeper (last I looked) requires the user to explicitly mark files as "edited" -- obviously
  • they *all* suck (Score:3, Interesting)

    by myowntrueself (607117) on Friday September 24, 2004 @05:36PM (#10344535)
    if someone can tell me of such a tool which can handle filesystem ownerships and permissions (in the context of Linux, in my case), and version them, I would like to hear it.

    At the moment I am using subversion because it has versioned properties and I wrote a bunch of scripts to extract filesystem metadata and create svn properties from them and vice versa.

    We have at least one arch fanatic where I work and when I asked him about this, he seemed to think that using arch for what I want would be *fantastic* and arch would rule, only I'd have to use the cvs method of maintaining ownerships and permissions, ie a script which maintains them in a file which is in the repository. Which I tried and which sucks.

  • by demi (17616) on Friday September 24, 2004 @05:52PM (#10344673) Homepage Journal

    I've been using arch for a while now. It's true that some of the setup is "too difficult"--it discourages adoption, but really, the documentation is quite good and example-laden.

    I think the two real weaknesses of Arch are (and neither of these are showstoppers for me and well worth the Arch-y goodness):

    • Lack of keyword substitution. I believe Tom's explicit position is that keyword substitution is properly the job of some kind of build or release system outside of version control, and that's probably right; but I like embedded version numbers and so forth.
    • Hooks are client-side-only. Since arch doesn't count on a particular storage backend or access method, it means you can't write hooks that force, for example, certain tests, or does notifications, upon commit or other actions on the tree. I think this is a more serious weakness; but to fix it might mean giving up the advantages of a server-free implementation.
  • arch is... (Score:5, Informative)

    by EsbenMoseHansen (731150) on Friday September 24, 2004 @05:53PM (#10344683) Homepage

    The good things about arch is:

    1. Changeset orientation --- patches are project oriented, not file-oriented, which is better (IMHO)
    2. Easy to make a private branch of a repository which you do not have access to
    3. Supposedly good merge mechanism
    4. Revisions are stored as simple changesets (patches) with only tarring and bzip2'ing.
    5. It has a lot of advanced features.

    The first two are why I use arch. The bad things are

    1. In Tom Lord's words, tla (the arch implementation) is a box of sharp knives. In other words, the interface is dangerous, uncomfortable, extremely badly documented and very clunky. E.g. simple operations like switching branch requires several commands and until all commands are executed the local version is in an inconsistent and unusable state
    2. It's very slow. When working from a local repository, it feel roughly like cvs on a public mirror. A patch to partly fix this was rejected.
    3. It uses just about every character available to the UNIX file system, including comma, =, {,} and more, and generates insanely long name. Some work is supposedly going on to fix the long names, though.
    4. To use safely, you have to know some graph theory. (I do, but I don't believe everyone should)
    5. Some commands are only safe if you have perfect knowledge of other users actions (star-merge).

    Oh yeah, the development has just sun-flared just when it had begun starting up again. A huge flame war (where Tom's primary contribution seemed to be "Grow up", "You're childish" and worse) arch is now without a release manager, and understandable nobody wants to take that role.

    In short, arch has great promise, but needs some drastic changes.

    • Re:arch is... (Score:3, Informative)

      by Sunthalazar (69878)
      Well the couple comments about 4,5 are partially because arch lets you do things that the other programs don't.

      The specific problems that are mentioned. If you have 2 branches, mine and yours. They are similar, but we've both been hacking on them.

      I merge you changes, and you merge mine, and then we both commit. This causes some conflicts later. If, on the other hand, I merge your changes, commit, and then you merge my changes and commit, everything works very well.

      The above poster was a little bit extra
  • Arch's biggest bug (Score:5, Interesting)

    by dozer (30790) on Friday September 24, 2004 @06:02PM (#10344758)
    A quote from an email conversation with an unnamed Arch user in January: "I think Arch's biggest bug is the one up the developer's collective asses."

    This article is a good example. Tom Lord just hand-waves his way past every question. Subversion sucks!!! CVS users are teh stupid!!! If he tones it down a bit, he definitely has a future in politics. But I don't think he's a very good software architect.

    OK, it's true that CVS and Subversion have problems. But, gak, so does Arch. Good God is it slow for big projects (something they've been promising to fix for years). And it's got some horrifying naming conventions: "tla--devo--1.3". And the files! "{arch}", "++default-version", ",,inode-sigs". Whatever Lord was smoking, it must have been good. The branching and merging operators are powerful but, thanks to all the punctuantion, they are also ugly. It's like the entire UI goes out of its way to be downright unfriendly.

    Every time someone mentions these deficiencies on the mailing list, they just get flamed for not truly understanding Arch. "Namespaces! Namespaces! Namespaces!" "Win32 is for lusrs!" Whatever. I just want a tool that helps me get the job done.

    Personally, I'm in the middle of transitioning to Subversion. It's better than CVS, and it is faster and nicer to use than Arch. Works for me.
  • What struck me as interesting about his comments is he only admitted to one flaw in Arch and he sort of mumbled it out: "...performance...won't bother most users...yadda, yadda, yadda".

    I find it hard to believe that Arch would be so perfect. If he really knew the strength of his software he would also have no problem admitting to its weaknesses and Arch would be that much better for it.

    Instead he spent most of the article attacking Subversion. If Arch is really that good, why would he spend so much time c
  • but in my (admittedly short) trial of arch I ran into a few show-stopping issues:
    no reliable cvs--tla converter (cscvs is under development)
    no GUI yet (necessary for some developers)
    doesn't install on AIX 4.3.3 (ugh...)
    These are all known issues under development (I wish I had time to help resolve them), and I'll try arch again in a while.
    As is frequently pointed out, arch is also very different than CVS.
    • by Anonymous Coward
      I refuse to use a software application where I have to invoke the author's initials to specify commands.

      Tom, change your name

      you narcissistic f'er
  • by iabervon (1971) on Friday September 24, 2004 @06:34PM (#10344953) Homepage Journal
    I'd be interested to hear if anyone has actually gotten happy with distributed development under arch. I tried a reasonably simple case a few weeks ago, and couldn't get it to feel right.

    What I was trying to do was to have a two-layer revision control system, where I have a private archive in addition to the project archive, and I check into the private one all the time, and transfer changesets to the project archive when I'm happy with it. That way, I can be halfway through refactoring a big chunk of code, have it completely broken, but have the work so far revision controlled so that, if I accidentally wipe out my build tree, I can recover it.

    The problem I ran into was that I couldn't get the two archives to agree exactly on the current status: whenever I transferred my changes up from the private archive, it added a log message to the project archive, and my private archive wasn't up to date, because it didn't have the message. When I updated my private archive from the project archive (either to pick up the message or to get other people's changes), I had to put in a log message, which the project archive then didn't have.

    It seems like arch really ought to support getting two archives in perfect sync, as well as disregarding a commit to a remote archive that only adds changesets already in the local archive (as well as disregarding the changesets themselves, which it does do).
  • by MemoryDragon (544441) on Friday September 24, 2004 @06:38PM (#10344969)
    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.
  • by glwtta (532858) on Friday September 24, 2004 @06:54PM (#10345106) Homepage
    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 [mit.edu] 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.

    • You're overlooking the all-important open source requirement: "I have to be the primary author". That's why there are so many aborted fetuses of open source software on SourceForge, Freshmeat, etc... starting from scratch seems sexy and it's all fun to write up project goals and mock up screen shots, but when it comes time to actually write the thing, and especially to write documentation and QA the thing, there's a lot of drudgery to be done.

      I'm using Subversion now, have been for about 6 months, and it's
  • Arch is a no go (Score:5, Informative)

    by Sunspire (784352) on Friday September 24, 2004 @07:36PM (#10345340)
    Arch just isn't a viable alternative for me or my team.

    1) It overestimates its own importance. It's just a version control system, yet it imposes restrictions on your coding practices. Specifically, you have to do out of tree builds or constant distcleans because arch assumes every file that gets created should be checked in, meaning there's a 1:1 mapping between the checkout directory and the repository by default. There's some work arounds, but it's a user-hostile stance to take and people moving from CVS/SVN will not accept this.

    2) The reason for the above is because "it's a feature of arch to encourage separation of source from builds". More like it is the easy way out of a lot of the tricky details with file renames and removals for the arch developers. Shit, why don't you just solve the tabs-or-spaces problem while you're at it, only allow checkings following the One True Way (tabs btw). I encourage Tom Lord to try separation of head from ass before he starts worrying about the cleanliness of my build tree.

    3) Tom Lord reminds me of a certain David Dawes (of Xfree86.org). It's just not that I personally don't like the guy, I could never commit my business or even hobby project to something lead by this man for the long term because I think the project has a high probability of self destructing.

    4) It's just unprofessional to blast the SVN developers. Newflash for you Tom: It doesn't matter if Arch is twice as good technically, SVN is good enough, familiar to CVS users and easy to use. They're all perfectly good reasons to go with SVN over arch, it's the reason MySQL is more popular than PostgreSQL. You don't see Postgres developers heckling MySQL, and Postgres is never, ever, going to overtake MySQL. Just be content with making the best versioning system, never mind what everyone else does.

    5) There's no Windows/OS X integration or even clients. That makes it a non-contender for any mixed environment, i.e. almost everywhere not counting projects being done in parent's basements.
    • Re:Arch is a no go (Score:5, Informative)

      by rweir (96112) on Saturday September 25, 2004 @03:37AM (#10347040) Homepage Journal
      Specifically, you have to do out of tree builds or constant distcleans because arch assumes every file that gets created should be checked in, meaning there's a 1:1 mapping between the checkout directory and the repository by default.

      Set "untagged-source precious" in the tagging-methods file. Yes, the default sucks for some people, but arch will work either way.

      More like it is the easy way out of a lot of the tricky details with file renames and removals for the arch developers.

      Erm, no, now you're just showing your cluelessness. Encouraging out-of-tree builds has nothing at all to do with renames, moves, or any other version control feature. If you build in tree, you will have NO problems at all with any of the things you mention here.

      There's no Windows/OS X integration or even clients.

      tla runs fine on OS X, as long as you have GNU diff, tar and patch. The windows port is seems to be working fine, albeit slowly. For all the whining about the lack of a Windows port, there's amazingly few actual contributors.

      For "integration", I assume you mean something like Tortoise{SVN,CVS}? Indeed, no one has written one of them yet.

  • by ndunn (171784) on Saturday September 25, 2004 @02:07AM (#10346832)
    I have been using arch for several months, moving completely over from CVS. Yeah, it fixes some of the stuff in cvs like moving directories and files. Its concept of branching isn't bad either. However, it completely fails simple things that cvs (and probably subversion) accomplishes with easy, like querying the differences between two branches without checking either out (the recommended solution is to check both out and perform diffs between them).

    There are other anomolies, like three different ways to update and/or merge branches, "update", "replay" and "star-merge". One version would be sufficient, with options which affect clobbering, etc.

    Other problems are the fact that it has to detect changes it frequently has to rebuild itself from branches back, which can tain several minutes as it goes through about 150 patch revisions. Of course, you can create a revision library to overcome this (I think).

    Don't get me wrong . . . I think that arch has the potential to be a great repository tool. Most of its problems could be overcome by simply automating sane defaults and allowing LESS choice. Currently, though, if I had to do merge my code over again, I would recommend against using it.

  • by master_p (608214) on Saturday September 25, 2004 @07:03AM (#10347565)
    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.
  • by Asmodeus (10868) on Saturday September 25, 2004 @10:45AM (#10348302)

    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

I use technology in order to hate it more properly. -- Nam June Paik

Working...