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

[Tom Lord]

    > From: Andrew Suffield <address@hidden>


    > Sure, renames would probably have to be treated like adds, and
    > cause a full scan (although I don't know that for sure, it's not
    > so obviously-safe so I'm not prepared to go there).

    > It seems fairly obvious to me that deletes and file-patches are safe
    > though: they operate only on a single logical file, and if we know
    > what the path to that file is, why do we care where all the other
    > files are?

    > I find a demand for proof of this rather like a demand for proof that
    > 1 + 2 =3D=3D 3 - it's so obviously true that I'm not sure how to start,
    > and the request makes me wonder if an axiom is missing or rejected.

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

For example, you circumscribed the applicability of your optimization
with:

        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.

except that, of course, every changeset in every archive contains at
least one add.

Another fun case that just occured to me is going to be auto-generated
ChangeLogs.   To get those right, a full inventory is needed --
period.  So, in fact, mason's optimization can't work at all -- nor
can your variations on it.

Overall though, even ignoring the ChangeLog issue -- you're setting
out to solve a very hard problem, a problem that is even hard to state
correctly in the first place, and proposing to work on that problem
where we have plenty of evidence that a conjunction of far simpler
hacks can accomplish nearly the same effect, far more obviously
correctly.  K.I.S.S.

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.

-t