Mark Phippard wrote:
> On Tue, Apr 1, 2008 at 9:49 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
>> So shall we:
>>
>> (1) Separate those options in the API(s)?
>>
>> (2) Not add any more command-line options now, but decide on a meaning for the
>> existing "--ignore-ancestry" flag now, that will set some combination of the
>> above options, and accept that we might want to supplement that with additional
>> flags in a later version. The meaning of the "--ignore-ancestry" flag now
>> should be one that closely fits its historical (pre-merge-tracking) *usage*
>> (rather than its implementation) and that also is not too confusing in the
>> presence of other options that we might want to provide later.
>
>
> I think it should stay the way it is and just take your original patch
> so that it works as it was intended. I recall when Mike P. added some
> of this that he was pretty clear that it had to ignore mergeinfo
> anyway, and I really cannot see it being that controversial for it to
> not write any mergeinfo when you use this flag.
>
> If we really did decide in the future that these need to be separated,
> which I doubt, then I do not see why we could not just change the API
> and introduce additional options at that point.
Right: maybe I'm making a mountain out of a molehill. The only essential thing
we have to do is ensure that we agree on the meaning of "--ignore-ancestry". If
and when Paul agrees that it should include "do not record any new mergeinfo"
as part of its meaning, then we're all set.
Paul, can you take a look at my floundering comments and questions in the
attached patch?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-01 16:37:20 CEST