Something changed shrink-revlog for the worse

[Dirkjan Ochtman]

On Mon, Jan 11, 2010 at 16:34, Greg Ward <greg at gerg.ca> wrote:
> I implemented this algorithm this morning and it's a big win.
>
> Repo #1: dummy merges do not "close the board down", so current
> toposort works pretty well, shrinking the manifest log from 2638 MB to
> 57 MB.  My new toposort shrinks to 52 MB: nice.  I was hoping it would
> be no worse, and am pleasantly surprised that it's a bit better.
>
> Repo #2: 30 dummy merges interrupt the flow of the trunk and reduce
> toposort's options.  Current toposort shrinks from 2638 MB to 468 MB:
> yuck.  My new toposort shrinks to 32 MB: awesome!!  I really did not
> expect this; I thought it would be much better than 468 MB, but really
> did not expect it to do *better* than repo #1.  A pleasant surprise
> indeed.

Sounds great.

> shrink: new toposort() which tries to avoid 'suboptimal' nodes.
>
> A 'suboptimal' node is one whose first parent is not its predecessor,
> i.e. one where revlog will compute a possibly large delta.  The
> theory is that minimizing suboptimal nodes will result in a space-
> optimal sort.  I have no evidence for this, but it feels right.

Yeah, seems to make sense.

I'd like to see what this does for Python and mozilla-central, maybe
someone else can test the difference on Linux.

Cheers,

Dirkjan