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: Chris Mason
Subject: Re: [Gnu-arch-users] [PATCH] arch speedups on big trees
Date: Fri, 19 Dec 2003 21:14:16 -0500

On Fri, 2003-12-19 at 20:33, Tom Lord wrote:
>     > From: Chris Mason <address@hidden>
> 
>     >> It's just that you're handwaving.    From my perspective you aren't
>     >> saying "1 + 2 = 3" you're saying "x + y = z  --- for example x might
>     >> be 1 and y might be 2 and z might be 3."
> 
>     > A changeset represents a known set of changes to the source
>     > tree.  ids aside, it should be possible to apply that known set
>     > of changes in roughly the same amount of time that patch would
>     > have needed.
> 
>     > File ids make the problem more complex, but I don't understand
>     > how that can't be solved with a reverse mapping from id to file
>     > name.  Most changeset operations should be on the order of the
>     > size of the changeset, not the size of the entire source.  We're
>     > smart people, lets find a way ;-)
> 
> Do you mean having, in the tree, a persistent mapping (e.g., a file)
> with the reverse mapping?  While conceptually possible, that would
> change the usage of arch in some significant ways (e.g., commands like
> `tla delete' would be needed more often than they currently are in
> both explicit and tagline trees).
> 

Well, any command that currently moves, deletes or adds an id would mess
with the reverse mapping at the same time. 

The rest seems easy in that special way things always seem easy before
you try it ;-)

> I overstated one thing -- your hack _can_ still work for exact
> patching.

But in the end, it's still a hack, and probably lowers maintainability
of the code.  I'll try again after xmas.

-chris






reply via email to

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