Converting from CVSNT

[Greg Ward]

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.  ;-)

Greg