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

[Tom Lord]

    > 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).

    >> The value to me of mason's experiment (now that the ChangeLog issues
    >> convinces me it can't be saved) is still that it shows how much that
    >> conjunction of simpler hacks can accomplish.

    > I'll have to read up on the changelogs, in my mind we're applying a
    > known set of changes, so we know what changed.  

    > But, only main goal for posting the code was to start discussion and
    > show things can be better.  If we get there from an entirely different
    > direction, great.

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

-t