Re: [Monotone-devel] git fast-export

[Markus Wanner]

Hi,

Derek Scherger wrote:
> I've spent a bit of holiday hacking time working on a git_export command for
> monotone, more as an experiment than anything else. I've committed the
> result to net.venge.monotone.fast-export for people to have a look at.

Awesome!

> Three exported branch names "net.prjek:tester",
> "net.prjet:tester/drop-for-propagate" and "prjek.net:tester" where changed
> (with sed) during the import process because git does not allow colon's (and
> various other characters) in branch/ref names. I simply changed ":" and "/"
> in these names to "." although the "/" should have worked it did cause an
> error of some sort.

Maybe respect those limitations within mtn git_export?

> The conversion was verified by checking out each of the 276 branches and 126
> tags from both git and mtn and comparing the resulting workspaces. The
> script I used to do this verification was a bit dumb and failed to checkout
> a few revisions so these weren't compared. Using only the branch name failed
> in some cases because there were multiple heads and using only a tag name
> failed in some cases because the tagged revisions had no branch certs. All
> of the branches and tags that did checkout were identical according to diff
> -qr so I'm reasonably confident that the new exporter basically works.

In my experience with cvs_import, it's rather often the history, than
the end result, which looks strange. However, that's certainly harder to
check and git seems a tiny bit closer to the spirit of mtn, than CVS.

> I suspect that the various other git fast-import conversion scripts that
> exist for monotone are probably slower and less robust than this
> implementation (unless they work similarly from rosters) which uses the
> monotone internals to do the work. I spent a bit of time initially trying to
> export revisions using the revision data structures but this didn't work
> very well. Git only deals with files and trying to order a mix of renames of
> directories and files from monotone correctly from revisions was difficult.
> Ultimately I didn't use the revision data structures at all but built up a
> similar files-only based revision representation by comparing rosters. Much
> like what is done for make_cset, but ignoring directories and producing only
> file deletions, renames and additions. This works much better, correctly
> handles pivot_root and a few other odd things that working with revisions
> proved difficult.

Sounds good.

> This exporter does not (yet) handle all rename ordering issues that are
> possible. For example <rename a b> followed by <rename b c> will probably
> fail on import unless it is executed as <rename b c> followed by <rename a
> b>. Similarly <rename a b> followed by <rename b a> which is indeed
> possible, will probably fail on import and requires the introduction of a
> third temporary file. These problems can be fixed in the exporter and can
> also be fixed in the exported data by re-ordering renames as required.

Hm.. maybe I just don't understand git fast-import format, but isn't the
ordering derived from the revision graph?

> This feels a bit like throwing in the proverbial towel and I hope this
> doesn't elicit any ill-will from the current monotone crowd. I'm not really
> planning on converting my personal stuff from monotone any time soon but
> knowing it can be done without losing information is nice.

You are definitely underestimating the mtn world domination plan (tm).

> I'm still happy
> to contribute to monotone but with 2 small kids my free/hacking time is
> pretty limited.

Very well understood.


Some questions aside: is there a "git fast-export"? Can you comment on
writing "mtn git_import"? Problems we are facing there?

Regards

Markus Wanner