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

From: Ian Clatworthy <ian.clatworthy@canonical.com>
Date: Oct 30, 2009, 03:50 UTC
Message-ID: <4AEA626D.8060804@canonical.com>
In-Reply-To: <fabb9a1e0910081058m59527600o392a6b438b18512e@mail.gmail.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.

Show 8 quoted lines

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

Show 7 quoted lines

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

Show 12 quoted lines

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

Show 5 quoted lines

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