Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

Heya,

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

On Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce [off-list ref] 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.

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.


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.

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.

Note: yes, I know that marks and date-format are features now, but
there's really no other suitable example that I could think of).

vcs fast import devs please ack this idea (and perhaps suggest
something other than "feature tool=git" if preferable) so that I can
reroll my gfi-options series :).

-- 
Cheers,

Sverre Rabbelier