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

Re: reverse-merge broken?

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2007-10-19 09:39:23 CEST

>> Jack,
>> Do you have any mergeinfo on a target from the corresponding merge
>> source?
> Yes:
> > svn plist -vR .
> Properties on '.':
> svn:mergeinfo : /branches/B1:4-16
> /trunk:3-7

This is the trigger of the failure.

>> Since a reverse merge is always going to be an explicit user
>> operation, maybe we ought to just not try to avoid repeat reverse
>> merges? The user has already signified they want to reverse the
>> merge, so why not just try to do it? What is the scenario where this
>> is going to lead to incorrect behavior?
> Yes, that would be more reasonable than the present behavior.
> Better than both might be:
> 1. look at the svn:mergeinfo for the revision in the -c-XX flag
> 2. find which revisions were added to the branch history by that revision
> 3. look in the svn:mergeinfo for the current version
> 4. if the revisions added in #2 are still present, remove them;
> otherwise print/return a warning that the named change set is not in
> this revision, so it can't be removed

This is very confusing to me.

In your dataset Step 1 gives
  svn:mergeinfo : /branches/B1:4-16

Step 2 may give (You did not mention the rev range of the merge+commit)
/branches/B1:4-16 (I am not sure how it got the merge from /trunk
probably it could be regular prop merge from branches/B1 which may be a
copy of trunk.)

It looks like this algorithm might work for us, but may not be feasible
to implement in a efficient way.

I have one thought.
What about *allow repeat reverse merge only for merge from the source
corresponding to target.*?

With regards
Kamesh Jayachandran

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 09:39:25 2007

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.