gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrew Suffield
Subject: Re: [Gnu-arch-users] [PATCH] arch speedups on big trees
Date: Fri, 19 Dec 2003 21:30:20 +0000
User-agent: Mutt/1.5.4i

On Fri, Dec 19, 2003 at 03:26:21PM -0500, Chris Mason wrote:
> On Fri, 2003-12-19 at 15:03, Tom Lord wrote:
> >     > From: Chris Mason <address@hidden>
> > 
> >     > Sorry, sounds like I need to understand arch merging better.
> >     > How is it different?
> > 
> > During mering, a file named by a changeset may not exist at all or may
> > exist at a different relative location to the top of the tree.  A file
> > or directory having the same relative path as something mentioned in
> > the changeset may, in fact, be a different file or directory (for the
> > purposes of patching).
> > 
> > In those cases where a mentioned file exists in the target tree (but
> > in a different place), arch_apply_changeset still needs to find it.
> > It uses the file id, not the relative path, to map (for example) a
> > .patch within the changeset to the file to which to apply that patch.
> 
> Gotcha, that is a problem.  It seems we should be able to detect most
> variations on this though (patching/deleting a file that doesn't exist,
> etc), and just trigger a full inventory.

Actually, that suggests a variation that makes more sense:

When we're trying to modify or delete the file with id X, we don't
really want to know the path of every file in the tree - just the one
with id X. So, start by asking "Does the file at path foo have id X?",
and if it does, stop. If it doesn't, scan outwards until we find it
(simplified form: scan the whole tree).

That'll require a bit of refactoring of the inventory interface, I
think, but shouldn't be too hard. It should work for any changeset
application.

Adding a file is the exceptional case - we have to scan the whole tree
for that. But it doesn't happen very often in general, so that's
probably a reasonable cutoff point for the optimisation.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]