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

[Ian Clatworthy]

Hi Shawn,

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.

Before I do that though, I thought I should ping you and other
fast-import hackers to check if any of you had any plans/needs along
those lines. Is there additional data required for round-tripping hg
repositories, for example, that I ought to allow for while designing the
extended format? If so, it would be good to pool our requirements so we
end up with one common extended format (not 10) and higher fidelity
migrations.

To be explicit, here's the sort of stuff I'm thinking of:

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

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

I'm sure more will be required (e.g. empty directory support, handling
differences in tag name rules, ghost revisions) so I'm hesitant to lock
down a detailed design without trying some code, but we should certainly
chat about some key policies w.r.t. extending the format ...

Do you have any preferred direction w.r.t. indicating extended vs
current data streams? For example, should we add a format command that
goes at the top of the stream something like ...

format (git|bzr) [version]

If missing, git 1.6 would be assumed. If present, old importers would
stop on finding a command they didn't understand?

Alternatively, we could put the format information (and all extended
metadata?) into meta-comments something like ...

#+ format bzr 2.0
...
commit /ref/heads/master
mark :22
author Bill Bloggs <bill at example.com> datetime
#+ author Sue Wong <sue at example.com>
#+ author Chuck Jones <chuck at example.com>
committer Sarah Watson <sarah at example.com> datetime
data 13
fix bug #1234
from :19
merge :21
#+ properties 2
#+ name 11 branch-nick
#+ value 12 bug-fix-1234
#+ name 5 fixes
#+ value 7 lp:1234
M 644 inline NEWS ...

I find that a lot less readable myself but it's worth considering.

Any needs, thoughts or comments?

Ian C.