|
From: | Thomas Lord |
Subject: | Re: MAINTAINERS file |
Date: | Thu, 06 Mar 2008 20:10:07 -0800 |
User-agent: | Thunderbird 1.5.0.5 (X11/20060808) |
Miles Bader wrote:
Thomas Lord <address@hidden> writes:Arch is "heavier" than other systems and, in some ways, is basically "doing more" (than, e.g., git) so, yes, it won't win prizes for commit times any soon.Geez, don't be silly Tom. The problem is that the arch implementation plays bugger-all attention to efficiency, That's nonsense and (unintentionally, I assume) insulting. It pays quite a bit of attention to performance. whereas git has had many people rabidly obsessing over every possible aspect of efficiency for years... There is some old mailing list message from Linus, around the time git was launched, that drives most of that. His very narrow aim (in the area it differs from Arch) was to make "commit" times as quick as possible. That was, more or less, his specific excuse for not using arch rather than writing git. Commit times are a strange metric to optimize for in a changeset-oriented system. There are plenty of other design goals and constraints to consider. Why not look at check-out times or file retrieval times? In many situations, for Arch, those are between O(1) and O(n) where n is the number of bytes in the revision? Or, if you really want git-speed (or better) commit times for arch -- that can be done with some *modest* coding by "committing to the revision library" and computing the changeset more lazily. (It'll still be slower than git since it's tracking file and directory logical identities to deal with renames reasonably, but it can be very fast. With a slightly more than modest approach you can probably even arrange to be usefully lazy about that and surpass git commit speeds. The big latencies in Arch are all about duplicating repositories (or fetching them in lieu of) and one-time costs of filling out caches. I still maintain that Arch imposes those costs at reasonable points in a reasonable work-flow on top of sane configurations of Arch. A weakness of Arch is that it is possible to use it poorly in ways that its performance contours punish. A related weakness is that, if you approach Arch expecting it to work like other systems, then you will be inclined to use it poorly in ways that its performance contours punish. So, it's not a dummy-proof program, by a long shot. Nothing to do with functionality. A lot to do with (a) bizarre hype about revision control tech w/in the open source world; (b) a culture of hacking in the open source world that generates work habits that don't easily give way to thinking about "changeset blogging" as a mode of revision control. (I use "open source" here deliberately to refer to a popular development methodology culture. Sadly, most free software seems to be developed using what popular opinion takes to be "open source methods".) -t |
[Prev in Thread] | Current Thread | [Next in Thread] |