Something changed shrink-revlog for the worse

[Benoit Boissinot]

On Mon, Jan 11, 2010 at 05:16:57PM +0100, Benoit Boissinot wrote:
> On Mon, Jan 11, 2010 at 10:34:31AM -0500, Greg Ward wrote:
> > On Sun, Jan 10, 2010 at 1:36 PM, Greg Ward <greg at gerg.ca> wrote:
> > > Conclusion: there exist small perturbations to the source revlog that
> > > cause large changes in the size of shrink-revlog's output.  I'm going
> > > to go spend some pencil-and-paper time now to see if there exists a
> > > tweak to the toposort() algorithm that does not exhibit this
> > > behaviour.
> > 
> > Got it!  I wasted a couple of hours yesterday trying to come up with
> > little heuristic tweaks to the current toposort algorithm, but then
> > had a brainwave late last night: if the idea is to avoid "suboptimal"
> > manifest nodes, i.e. nodes whose predecessor is not their first
> > parent, then start at the heads and work backwards.  Then there's no
> > guessing required: you just follow the trail of first parents for as
> > long as you can.
> 
> I don't see why first parent matters. Except if you have a special case
> (like more stuff happening on trunk, that's probably what happens for
> you) either parent should work.
> 
> Did you try a simple DFS ?

It's actually what you did, you don't use the order of the nodes, right?

Benoit

-- 
:wq