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

[Sverre Rabbelier]

Heya,

On Tue, Aug 25, 2009 at 07:57, Shawn O. Pearce<spearce at spearce.org> 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.

Perhaps then it makes sense to store the 'extra' information in a
per-tool storage, similar to the per-tool options?

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

Adding 'feature' support sounds more useful by the minute (and
backporting an 'This feature is not supported' message displayed for
all feature commands to old fast-imports).

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

What about 'feature import-git-marks'/'feature import-bzr-marks', etc,
or perhaps a 'tool git'/'tool bzr' command to tell the importer that
it's trying to import a stream for a specific tool (and as such should
abort if it's a different tool).

> 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

I don't think we need to make feature_name a path_str, something like
[a-zA-Z_-]+ is probably enough? Also I don't know about the '='
path_str part, do we really need that? Isn't it easier to support:
'feature baz\nfeature bar-foo' than 'feature baz\feature bar=foo'?

>  # Must be skipped by parser if vcs_name does not match self.
>  # Must be understood by parser if vcs_name matches self.
>  #
>  option      ::= 'option' sp vcs_name sp option_name ('=' path_str)? lf
>  vcs_name    ::= ('git' | 'bzr' | 'hg' | path_str)
>  option_name ::= path_str

Now here we do need the '=' path_str part, but again I don't think
option_name has to be a path_str, same for vcs_name.

>> feature file-commands-apply-to-committed-state
>
> :-)

I must not have been paying attention; what do file commands apply to currently?

-- 
Cheers,

Sverre Rabbelier