From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: MAINTAINERS file Date: Thu, 06 Mar 2008 20:10:07 -0800 Message-ID: <47D0C01F.60100@emf.net> References: <18375.18663.981150.252393@kahikatea.snap.net.nz> <87od9wt19m.fsf@elegiac.orebokech.com> <87tzjnvjhc.fsf@red-bean.com> <87ablffdf7.fsf@catnip.gol.com> <4s4pbm9lrb.fsf@fencepost.gnu.org> <87skz4n6lu.fsf@catnip.gol.com> <87r6enpy30.fsf@catnip.gol.com> <47D050B0.1060608@emf.net> <87fxv3pf6o.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060008070708020006070101" X-Trace: ger.gmane.org 1204857188 17706 80.91.229.12 (7 Mar 2008 02:33:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Mar 2008 02:33:08 +0000 (UTC) Cc: Glenn Morris , rms@gnu.org, lekktu@gmail.com, emacs-devel@gnu.org, kfogel@red-bean.com, Stefan Monnier , paul.r.ml@gmail.com To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 07 03:33:34 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JXSOb-0005oM-3E for ged-emacs-devel@m.gmane.org; Fri, 07 Mar 2008 03:33:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXSO3-0007Ya-FU for ged-emacs-devel@m.gmane.org; Thu, 06 Mar 2008 21:32:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JXSO0-0007YL-3r for emacs-devel@gnu.org; Thu, 06 Mar 2008 21:32:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JXSNy-0007Y9-Hy for emacs-devel@gnu.org; Thu, 06 Mar 2008 21:32:38 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXSNy-0007Y6-D7 for emacs-devel@gnu.org; Thu, 06 Mar 2008 21:32:38 -0500 Original-Received: from mail.42inc.com ([205.149.0.25]) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1JXSNm-0006D6-Tb; Thu, 06 Mar 2008 21:32:27 -0500 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.65.4] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 24745851; Thu, 06 Mar 2008 18:32:04 -0800 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <87fxv3pf6o.fsf@catnip.gol.com> X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:91577 Archived-At: This is a multi-part message in MIME format. --------------060008070708020006070101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Miles Bader wrote: > Thomas Lord 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 --------------060008070708020006070101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Miles Bader wrote: 
Thomas Lord <lord@emf.net> 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

--------------060008070708020006070101--