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

[Ian Clatworthy]

Shawn O. Pearce wrote:

> I'm really worried about having a "bzr bug ..." and "hg bug ..." and
> then hg trying to read the "bzr bug" line in addition to the "hg bug"
> line, but bzr only reading the "bzr bug" and an hg->bzr conversion
> sliently failing because the bzr importer doesn't know how to read
> the "hg bug" data.

I agree it's an issue. There are similar challenges around .xxxignore
files. Let's drop the idea of tool specific options. If required, we can
prefix some properties with the tool name if that proves necessary in
practice.

> Actually, one option, "option date-format={raw|rfc2822|now}" is
> probably something that should be a standard in the format, since
> it says how the dates are encoded.  A tool which doesn't understand
> rfc2822 dates should abort and not try to process the stream.

Couldn't that simply be ...

feature date-format=rfc2822

> But clearly "option export-pack-edges=<file>" is git specific,
> and has no meaning for bzr or hg, or any other system.  It likely
> should be "option git export-pack-edges=<file>", so that a git tool
> would honor it, but a non-git tool would silently skip it.
> 
> Somewhere in the middle is "option import-marks=<file>".  The
> git-fast-import tool knows how to save and reload marks, which
> are tied to Git SHA-1s, so its unlikely a git marks file would
> be useful to any other tool, but other tools might also support
> loading and saving marks across runs.  I don't know.  The option
> is here so the stream generator can clearly signal to the parser
> that the mark database should be picked up from a prior state in
> order to parse the stream correctly.
> 
> We haven't yet made this change to git.  We could modify this to
> take a VCS name.

I'd prefer keeping processing options out of the stream altogether. If
you want a collection of processing options, store them in a separate
file ala cvs2svn. Each tool can then have a small options file specific
to it with *suggestions* on how to process it. Users can tweak the
processing by changing that small file without risking corrupting the
metadata.

To put it another way, I think the fast-import format ought to focus on
the metadata itself and that the 'feature' feature you suggested is
enough to achieve that.

BTW, most (but not all) import/export tools support marks files now. The
internal ID can vary though, e.g. for Bazaar exports, we store
':mark revision-id', not ':mark SHA1'.

> Maybe "feature" (see below) is required to be understood, and
> date-format should be a "feature", while "option" can be skipped only
> if the VCS name which appears in the option line is not yourself?
> 
>   # Must be understood by parser, or parser must abort.
>   #
>   feature      ::= 'feature' sp feature_name ('=' path_str)? lf
>   feature_name ::= path_str

As Sverre suggested, I think feature-name can be just [A-Za-z_]. I
didn't think the "= xxx" bit was needed but I've just used it in my
example above. :-) It could have just as easily been date-format-rfc2822
though.

Ian C.