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

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

Re: [Gnu-arch-users] larger trees slowing down


From: Chris Mason
Subject: Re: [Gnu-arch-users] larger trees slowing down
Date: Wed, 28 Jan 2004 09:20:06 -0500

On Wed, 2004-01-28 at 09:00, Aaron Bentley wrote:
> On Tue, 2004-01-27 at 16:22, Dustin Sallings wrote:
> > 
> > On Jan 27, 2004, at 12:49, Aaron Bentley wrote:
> > 
> > > We have to make
> > > sure that we modify the right file, and in order to do that, we do a
> > > whole-tree inventory, to find out the id -> filepath mapping.
> 
> >     I suppose this makes sense for ``foreign'' patches, or cherry picking  
> > or whatever, but it doesn't make much sense at all in the case of a  
> > get.  Any rename is going to be done by the patch itself, and all  
> > subsequent patches will use the new name.
> 
> I agree.  We do have to tread lightly with that code, since a bug there
> would be disproportionately dangerous.  
> 
> A general solution would
> - allow the caller to provide hints as to what files to look at first

my code does this

> - allow the caller to specify the required ids, so we can stop the
> inventory when we have all of them.
> 
But not this

> That would cover foreign patches as well as exact patching, and would
> have much better performance than the current code.  
> 
> It wouldn't catch (corrupt) changesets with duplicate IDs, which I
> expect the current code does.

It does catch duplicate ids, but needs to be updated to include the
inode signatures again. 

The main thing I'm waiting for at this point is details from Tom on
where he wants the design of the code to go.

-chris






reply via email to

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