Subject: Re: [Gnu-arch-users] Re: darcs vs tla
From: Catalin Marinas <catalin.marinas@arm.com>
To: Robert Collins <rbcollins@cygwin.com>
In-Reply-To: <1100306258.7511.56.camel@localhost>
References: <20041107234609.7bf0abfe@delta.hk.office.outblaze.com>
	<tnxlldcbqm1.fsf@arm.com>
	<D4D5B1A3-31DC-11D9-B0B3-000393CFE6B8@spy.net>
	<1099995711.2900.84.camel@stargate>
	<1100306258.7511.56.camel@localhost>
Content-Type: text/plain
Message-Id: <1100517922.2723.61.camel@stargate>
Mime-Version: 1.0
Date: Mon, 15 Nov 2004 11:25:22 +0000
Content-Transfer-Encoding: 7bit
Cc: Arch Users <gnu-arch-users@gnu.org>, Dustin Sallings <dustin@spy.net>,
        Timothy Webster <timw@outblaze.com>
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 2609
Lines: 62
On Sat, 2004-11-13 at 00:37, Robert Collins wrote:
> On Tue, 2004-11-09 at 10:21 +0000, Catalin Marinas wrote:
> > I suspect arch would also be a bit slow for a rate of 50 patches/day.
> 
> I have a checkout here of goerzens linux tree. Using roughly tla 1.3,

Where is this tree?

> I'm pretty sure the inode signatures where out of date in that tree. So
> I grabbed a clean copy, and applied the same delta:
> (cold): 0m14s
> (hot):  0m7s

For a 2.6.9 kernel with only 2 files modified, "tla changes" took around
40s (real time) and the inodes list seems to be up-to-date (any way to
ensure this?). I have a quite fast machine, probably similar to yours.
The tree is hard-linked to the revision library (it took around 1m6s for
an unlinked tree).

Successively applying patches to a tree also needs to add the revision
to the library. A "tla changes" without the current revision in the
library took 1m on my machine (having the previous revisions in the
library as well).

All these figures look _very_ good to me. I was mislead by a test which
was generating a revision in the library from a 18MB patch. This took
4m40s (which would be unacceptable for the number of changesets in the
Linux kernel - ~1420 since 2.6.9 until now, but which are quite small).

> Note that the above performance metrics are from not hardlinked trees.

Why would it make any difference if the inodes list is up-to-date? Tla
shouldn't probably look at the revision library for other files than the
changed ones.

> Arch can do single patch merges, I wrote pure-merge.sh ages ago (2 years
> I think) which does precisely that, automatically, but doesn't handle
> all the cases of conflicts that can occur. Andrew Suffield and I
> hammered out the algorithm for handling those, but no ones implemented
> it in the intervening time. 

I suspect pure-merge was based on "tla replay". If the changes in you
tree modify the context of one of the patches to be applied, pure-merge
would fail. You can fix it and continue. Darcs' commuting operators
allow all the merging to be performed and report the conflict only at
the end. This is quite good since an early patch can be modified by a
later one and you might not be interested in fixing the first conflict
but fix the final result only (as I said in a previous e-mail,
star-merge --three-way gets quite close to this but loses the individual
changes).

Catalin


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/