Kamesh,
There is only one attempted reverse-merge in my example, and indeed
that one doesn't do anything so far as I can see, so in some sense
there are zero. I don't understand, then, why you end up asking
questions about *repeat* reverse merges.
Perhaps your thought is, more or less, "we have to do something or
other about repeat reverse merges, so what policy is acceptable on
that?"
I would respond that no policy toward repeat reverse merges is
acceptable, if it means that simple reverse merges are broken.
Indeed I can't see what meaning there is to a policy on _repeat_
reverse merges, if the initial reverse merge can't happen!
On Oct 19, 2007, at 9:39 AM, Kamesh Jayachandran wrote:
>
>>> 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
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 18:16:41 2007