Request for help adding Mercurial output to cvs2svn

[Alexis S. L. Carvalho]

Thus spake Steve Borho:
> 
> On Fri, 2008-02-22 at 22:24 +0100, Michael Haggerty wrote:
> > Another, perhaps more sensible way to help conversions to Mercurial
> > would be if Mercurial would offer a "hg-fast-import" tool similar to
> > git-fast-import [1] and bzr-fastimport (which was just announced on the
> > bazaar mailing list):
> > 
> > Ian Clatworthy wrote:
> > > I'm pleased to announce bzr-fastimport, a plugin useful for loading
> > > data exported by a large number of foreign VCS tools. Places to start
> > > are:
> > >
> > > * the Launchpad page - https://launchpad.net/bzr-fastimport
> > > * the Wiki page - http://bazaar-vcs.org/BzrFastImport.
> > >
> > > Please note that this is not yet production quality but seems to be
> > > working well enough to be useful for a large number of projects.
> > > [...]
> > 
> > These tools accept data in a well-defined and well-documented serialized
> > stream format and load it into the corresponding VCS.  The formats
> > consumed by git-fast-import and bzr-fastimport are largely compatible.
> > Since cvs2svn can already generate git-fast-import output, the new
> > Bazaar tool has effectively just added a "cvs2bzr" mode to cvs2svn and
> > to other similar conversion tools.
> > 
> > (Subversion has an analogous "dump" format, which is used by cvs2svn
> > when converting to Subversion.)
> > 
> > Wouldn't it be great if the Mercurial project would develop an
> > hg-fast-import tool?  That way the part of the conversion process that
> > is tightly connected to Mercurial itself could be maintained by the
> > Mercurial project, and I could devote my energy to tweaking the stream
> > output of cvs2svn to best match the things that are different between
> > Mercurial and git/bzr.  Ideally, hg-fast-import would accept a stream
> > format as similar as possible to git-fast-import's.
> > 
> > I haven't been psyched about trying to tie cvs2svn so intimately to
> > Mercurial and having to track Mercurial changes, all from within a
> > separate project.  This seems like a very good way to decouple the
> > programs and make the combination much more maintainable.
> 
> Any reason not to use the existing Mercurial bundle format?  Is it just
> not documented well enough?

It's too tied to the internal structures used by Mercurial - it'd be
easier to call commit N times and then hg bundle then to generate the
bundle directly.

An hg-fast-import is not so easy to write.  Some hg-specific problems
that would pop up:

- hg stores the file revisions in topological order (parents before
  children)

- there's a pointer from file revision to changelog revision (linkrev)

- auto-merging of .hgtags

It's certainly possible to solve these, but it won't be trivial.

Alexis