emacs-devel
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MAINTAINERS file

From: Thomas Lord
Subject: Re: MAINTAINERS file
Date: 2008年3月06日 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

reply via email to
[Prev in Thread] Current Thread [Next in Thread]

AltStyle によって変換されたページ (->オリジナル) /