Any plans/needs to extend the fast-import format?

[Greg Ward]

On Mon, Aug 24, 2009 at 10:19 PM, Ian
Clatworthy<ian.clatworthy at canonical.com> wrote:
> I'd like to use bzr fast-export + bzr fast-import to "round-trip" Bazaar
> branches but the format doesn't currently support all the metadata I
> need to do that. One option is to extend the above tools to use a
> superset and only dump the additional data if requested.

Sorry for jumping in late, but from the cc list it looks like I'm the
voice of the Mercurial community here.  (Yikes!)

> * An optional properties section in a commit. Each property would
>  have a name and value, both utf-8 encoded.

+1 on this, since it's the most natural way to encode Mercurial's
'extras' dict.  Currently the only important thing that 'extras' is
used for is the branch name, which obviously already has a place in
fast-import.  But there is one obscure Mercurial feature that cannot
be represented in a fast-import stream, the "branch is closed" flag.
AFAIK that flag is the only info that would be lost round-tripping an
hg repo through fast-import.

But it's possible that extensions or future Mercurial versions would
put other things into 'extras' -- after all, it's an arbitrary
key/value mapping.  So lossy round-tripping is a *potential* problem,
and the obvious answer is to allow an arbitrary key/value mapping in
each commit of a fast-import stream.

> * Multiple author sections in a commit, not just one. (I guess authors
>  beyond the first wouldn't need the when data so I'm leaning towards
>  leaving that out.)

IMHO Bazaar's support for multiple authors is the best argument for
extending fast-import.  You might lose info if you try to go
bzr->fastimport->{git,hg}->fastimport->bzr, but that's the fault of
the intermediate git or hg not representing multiple authors.  (Same
problem with committer != author going from {git,bzr} through hg: that
is (IMHO) a Mercurial problem.)

> I'm sure more will be required (e.g. empty directory support, handling
> differences in tag name rules, ghost revisions)

Now you're getting into increasingly arcane Bazaar functionality.  I
mean, anyone can understand "directories are first class objects" as a
distinction between Bazaar, Git, and Mercurial.  And you can make a
case that fast-import should have the ability to represent directories
as first-class objects, as long as it's OK for git and Mercurial to
ignore that info.  But what the heck is a ghost revision?  (Rhetorical
question: I can STFW if I'm really curious.)  I'm *not* a fan of
lowest-common-denominator interchange formats; that way, *everyone*
loses.  But trying to accomodate every feature of every popular VC
system could be a nightmare.

Greg