Re: [Gnu-arch-users] [PATCH] arch speedups on big trees

[Chris Mason]

On Fri, 2003-12-19 at 17:25, Tom Lord wrote:
>     > From: Chris Mason <address@hidden>
> 
>     > Unfortunately for me, the patches I work with do add files frequently. 
>     > But things only break down if we're trying to prevent the addition of
>     > files with duplicate ids in different locations during a merge.  Does
>     > the current code prevent that?
> 
> By current code you mean before your patch?  Yes.  It's a conflict.
> (There's an exception regarding patch logs.)

Ok, this should be safe, but slower.  It triggers a full read any time
you add files/dirs/symlinks, or when the apply changeset code detects
problems like trying to apply a patch to a file that doesn't exist.  My
test dir has 20 changesets that add files, so the tla replay time goes
up to 1m23s.  Unpatched arch runs at 7 minutes.

The next step is to find a way for the user to tell us to trade safety
for speed, both on merges and regular pulls.  But I wanted to get a
starting point that should work safely for both.

I tested this with a rename (tla mv foo foo.1, tla replay 'patch that
changes foo'), and it worked as expected.  All the other cases are
untested ;-)

-chris

arch-faster-2.diff.gz
Description: GNU Zip compressed data