Something changed shrink-revlog for the worse

Benoit Boissinot benoit.boissinot at ens-lyon.org
Tue Jan 12 07:14:53 CST 2010


On Mon, Jan 11, 2010 at 09:07:51PM -0500, Greg Ward wrote:
> On Mon, Jan 11, 2010 at 8:48 PM, Greg Ward <greg at gerg.ca> wrote:
> > Correct: my toposort is completely driven by topology, not revision
> > order.  That's deliberate and it's a big win in my case.
> 
> Forgot to mention: the idea that inspired my reverse DFS (or whatever
> we call it) algorithm was, "How would the manifest look if Mercurial
> actually had parent deltas today?"  Presumably revlog would compute
> each delta relative to parentrevs(rev)[0], not to rev-1.  Obviously
> the order of manifests would be different, but I think my algorithm
> captures the deltas that would be written by a parent-delta revlog.

That's the same idea with the original algorithm, except the branch it
chooses is more random.
> 
> Or at least that was the idea.  For me it's enough that 1) it's
> correct and 2) it gives me a 35 MB manifest.  After that, everything
> else is secondary.  (Unless someone comes up with an algorithm that
> gives me a 20 MB manifest, in which case I will happily abandon ship
> and latch onto their great idea.)

Could you verify that the "postorder of the reverse DAG" gives the same
result as your algorithm?

If that's the case I think we should go this way, since it's the
textbook implementation of the DFS algorithm.

After that the only variable that matter is the order we visit the
parents. You choose the order from the way they were stored, but we can
imagine other schemes (default branch vs other, size of the diff, etc.).

regards,

Benoit

-- 
:wq


More information about the Mercurial-devel mailing list