[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Re-merge a change from own history - corrupts svn:mergeinfo

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 01 Apr 2008 15:37:01 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.