Re: [Gnu-arch-users] Fast commits

[Tom Lord]

    > From: Robin Farine <address@hidden>

    > I know where to find it based on the <p>--<b>--<v> tuple, no need for 
    > the patch level. But in fact, what looks like being time consuming when 
    > committing from a working tree containing a patch log of about 10'000 
    > logs is the traversal of the patch log directory in the working tree.

Which is completely unsurprising.   I can't think of any good reason
to have that many patch logs in your tree.

I _can_ imagine hugely-scaled projects in which we want more than
ad-hoc mechanisms for patch-log pruning and restoration (i.e., prune
on the way up from many, many leaf branches to a mainline --- then
restore in dribs and drabs when merging back from the mainline).


    > I thought that knowing the patch number would help, but now I realize 
    > that the computation of the change set includes this traversal and a 
    > similar traversal in the reference revision. So yes, the only reasonable 
    > solution in such a situation is to have more versions and to prune logs 
    > like hell.

Yup.  There's no rocket science here.  We can prune and perhaps
restore in very automatable and handy ways (dozens of lines of new
code).  But it's kind of a chicken-and-egg problem from my
perspective, at the moment ---  I kind of want to run head-on into the
theoretical problem first hand before I pick the dozens of lines of
code needed to solve it.


-t