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

[Ian Clatworthy <ian.clatworthy@canonical.com>]

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 <spearce@spearce.org> wrote:
>> 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).

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

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