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

Re: Symmetric Merge

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 22 Mar 2012 21:33:44 +0000 (GMT)

>> Julian Foad wrote:

>>> I suggest we should leave the --reintegrate option available,
>>> meaning "do stricter checks", and after doing the checks
>>> it will run the symmetric merge code.  Currently the checks
>>> are "no local mods" and "no switched subtrees"
>>> and "no cherry picks"[1], in addition to the "no mixed
>>> revs unless overridden" that applies to all merges.

Mark Phippard wrote:
>> Let me just see if I understand what you are saying here (only talking
>> about what is now a "reintegrate" scenario):
>>
>> 1) User could just run svn merge.  Merge will do the right thing, but
>> the existing reintegrate checks would not happen.
>>
>> 2) User could also use svn merge --reintegrate.  Merge would still do
>> the right thing, but the additional checks would happen.

Yes and yes.

>> Or are you saying that 1 and 2 will be the same no matter what and the
>> code will just figure it out?

No.  In either case, the code will figure out (in just the same way) what merge needs to happen.  The high-level meaning of the "reintegrate" option would be merely something like "I believe I'm merging into a clean simple WC and I haven't been doing any cherry picking, so please alert me if you detect otherwise".

>> As an API consumer via JavaHL, I would assume I will just have a
>> single merge API I can run, as opposed to two today.  And the API will
>> do the right thing?

Yes.

Branko Čibej wrote:
> I'm confused. What additional checks would --reintegrate do that your
> common or garden merge would skip? What kind of check do you think you
> can safely skip without throwing all the effort you're putting into
> fixing the merge algorithm out the window?

The checks of target WC state mentioned above.  Of course, the name "reintegrate" would then be less than appropriate, and we could consider a new name that makes more sense for that "I expect this to be a clean simple merge" kind of meaning.  Is the use of an asymmetric-sounding option name for a now-symmetric functionality what was making you uncomfortable?

> I've been assuming all along that --reintegrate would simply become a
> backwards-compat no-op.

We could do that, but I believe the checks it does are useful in that kind of scenario.  (I even have an idea how we might want to expand the checks further.)

- Julian
Received on 2012-03-22 22:34:19 CET

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