Re: [Gnu-arch-users] Re: darcs vs tla

[Catalin Marinas]

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