Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)

Sverre Rabbelier wrote:

Heya,

[edited Shawn's message somewhat to be more relevant to vcs-fast-import-dev]

Thanks Sverre. Before I start, sorry for taking so long to reply to this.

On Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce [off-list ref] wrote:

quoted

IIRC my problem with options was we weren't enforcing them, and yet
they were necessary for a successful import, e.g. import-marks or
export-marks.  A minor error could cause a successful looking import
that is wrong due to the marks being messed up, or not saved out.

So I was leaning towards making these features, but then they
aren't necessarily compatible with the other fast-import tools.

My strong preference is for:

* feature = anything impacting semantics
* option = tool-specific with no impact on semantics permitted.

Both features and options ought to OS independent (where possible).

quoted

I think we want to declare features for import-marks and export-marks:

 feature import-marks=in.marks
 feature export-marks=out.marks

and define these as paths to local files which store a VCS specific
formatted mapping of fast-import mark numbers to VCS labels.

+1 to making these features and to tightening up the semantics so we can
reliably use them across tools. Explicitly specifying the local path
names worries me though. Consider someone using fastimport tools to
maintain multiple mirrors in different tools:

1. Step 1 is fast-export from tool A
2. Step 2 is fast-import into tool B
3. Step 3 is fast-import into tool C

What should the stream look like then? Does it need to change if we want
an additional mirror in tool D? (Note that the mark files will need to
be reused to transfer changes back to the master.)

quoted

Other options that are clearly git should be declared as:

 option git max-pack-size=2048

with the meaning of option being declared something like:

 If the parsing VCS name appears as the first argument, the parsing
 VCS must recognize and support the supplied option, and if not
 recognized or not supported must abort parsing altogether.

 If the parsing VCS name is not the first argument, it must entirely
 ignore the option command and not try to process its contents.

+1. By forcing tools to know about options specific to them, we avoid a
range of bugs processing newer streams with older tools.

I think it makes to ignore options that are not for our vcs, as long
as options that change import behavior (such as marks, date-format)
are combined with, say, 'feature tool=git'. This way we can be sure
that when outputting out a vcs specific stream, it is only parsed by
that vcs.

I don't think options should be permitted to change import behavior. In
other words, we should actively discourage vcs-specific streams. Any VCS
using features has a (moral) responsibility IMO to at least define those
publicly. Here's a poor start (EBNF syntax would be far better than just
text) on the Bazaar side:
http://doc.bazaar-vcs.org/migration/en/data-migration/fast-export.html#interoperability.

Maybe we need a central wiki page (say) where these can be registered?
I'd offer to setup a "fastimport" web site in a Bazaar branch and track
feature specification bugs in Launchpad but maybe a wiki page would be a
little more neutral ground. :-) :-)

Ian C.