Converting from CVSNT

[Matt Mackall]

On Tue, 2009-06-30 at 17:42 -0400, Greg Ward wrote:
> On Tue, Jun 30, 2009 at 5:28 PM, Michael Haggerty<mhagger at alum.mit.edu> wrote:
> > Please correct me if I'm wrong in inferring that Mercurial doesn't care
> > whether the commits are in chronological order, but benefits from having
> > similar revisions near each other because the revlog format computes
> > diffs between revisions that happen to be adjacent in the file, not
> > revisions that are adjacent in the DAG.  (I always wondered how the
> > revlog format represents branches, since it seems like such a linear
> > format.  Obviously the answer is that it *doesn't* represent branches
> > very efficiently, at least in the general case.)
> 
> That's a nice clear, elegant explanation.  But I don't know how
> accurate it is; perhaps someone with a deeper understanding can
> enlighten us.
> 
> > Anyway, if is it not too much work to determine a more advantageous (in
> > the sense of "efficient for Mercurial") ordering from among all of the
> > topologically valid choices, maybe cvs2svn could generate the changesets
> > in that order.
> 
> That feels wrong.  If there exists an ordering that makes Mercurial
> more space-efficient (and therefore time-efficient), shouldn't code to
> determine and impose that ordering live with Mercurial?
> 
> > On the other hand, it might make more sense to develop a tool that can
> > optimize an existing Mercurial repository.
> 
> Bingo... at least as a short-term measure.  What you're looking for is
> contrib/rewrite-log with Benoit Boissinot's patch to reorder the
> manifest.  I'm not sure where the canonical version of that patch
> lives; not in any of the official Hg repositories.  I keep a copy in
> my personal patch queue just because I thought it might be handy to
> have.
> 
> > It seems to me that such a
> > tool could usefully be applied to repositories that have been in use for
> > a while--a kind of "defragmentation" of lines of development, or "hg
> > repack" by analogy with git.  Then the convert extension wouldn't have
> > to deal with this issue at all.
> 
> Keep making suggestions like that.  With any luck, MPM will be so
> outraged by the idea that Mercurial needs a "pack" operation that
> he'll either 1) fix the problem or 2) explain how to fix the problem
> so someone else can do it.  ;-)

The solution has been known for some time: parent delta.

-- 
http://selenic.com : development and support for Mercurial and Linux