Reusable fastimport parser

[Greg Ward]

On Tue, Apr 21, 2009 at 11:30 AM, I wrote:
> no doubt you folks are aware that there is well designed, high
> performance, low overhead, pure Python parser for git's "fastimport"
> format in bzr-fastimport.  The original author of hg-fastimport
> clearly liked it enough that now we have two copies of Ian
> Clatworthy's fastimport parser kicking around the net: hg-fastimport
> is basically a fork of bzr-fastimport with the backend rewritten to
> produce a Mercurial repository.
[...]
> So... I'd like to heal the fork before it gets bad.  IMHO the best
> option would be factor out the non-Bazaar-specific bits of
> bzr-fastimport and put them in a common library that both
> bzr-fastimport and hg-fastimport depend on.

Phase 1 is well underway: see
https://launchpad.net/~gward/bzr-fastimport/reusable .  That branch is
derived from Ian's canonical bzr-fastimport branch, and it is now a
stripped down, standalone Python library that passes its tests.  It
still has some dependencies on bzrlib, but most of them look to be
shallow and easy to fix (e.g. use standard 'logging' module instead of
bzrlib.trace.)

So far I have made no substantial changes to the code; all I have done
is rearrange things.  I'm not sure how far I'll be able to go without
making changes: e.g. while trying to use hg-fastimport, I have been
bitten by a couple of bugs in the parser; if those bugs are still
present in bzr-fastimport, then they will be present in my fork, and I
will write tests and fix them.

So... before I go too far down that road, I'd like to hear some
feedback from the Bazaar folks.  Especially Ian, obviously.  In
particular, do you think this is a worthy endeavour, and are you
receptive to me providing a patch to bzr-fastimport that makes it
depend on "my" new standalone fastimport library?  Or would you rather
proceed differently... e.g. include a copy of the library with
bzr-fastimport, and manually resync to get fixes and features as
required.

Thanks --

Greg