>> 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
/trunk:3-7
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