[Svnmerge] overzealous exclusion of reflective merges?

[Reid Priedhorsky]

Dustin J. Mitchell wrote:
> On Fri, Jun 6, 2008 at 4:47 PM, Reid Priedhorsky <reid at umn.edu> wrote:
>> 1. create branch A by copying TRUNK
>> 2. make some changes on A and commit them
>> 3. make some changes on TRUNK and commit them
>> 4. merge these changes on A back to TRUNK:
>>    a. svnmerge merge
>>    b. some edits -- fix conflicts, maybe some other changes
>>    c. commit
>> 5. make some more commits on TRUNK and commit them
>> 6. merge TRUNK to A
>>
>> But then A is missing some changes made on the trunk.
>>
>> I _think_ the changes that are being missed are those that occurred in
>> Step 4b. I hypothesize that svnmerge assumes in Step 6 that Commit 4c is
>> reflective and omits it -- but it shouldn't be, since what I committed
>> was not exactly what was merged. I could push the "other" changes to a
>> second commit, but I have to fix the conflicts before Subversion will
>> let me commit (and it seems reasonable that these conflict repairs would
>> be useful on Branch A too).
> 
> You're exactly right, though.  A commit is the finest-grain change
> that svnmerge can reason about.  How would it be able to differentiate
> the (conflicted) merged changes from the unique changes made in trunk?
>  Even if it could, how would it apply those changes to the branch
> (since they would doubtless cause conflicts there, too)?  This is a
> problem for any VC that's supporting multiple parallel lines of
> development.  There's no solution, really -- although some VC's do a
> better job than others.
> 
> When you merge the changes from step 3 to the branch, you should see
> the "mirror image" of the conflicts you resolved in step 4b.  Ideally
> you'd resolve the conflicts just as you did in 4b, leaving branch and
> trunk identical.

I have to manually fix the same conflicts twice? That doesn't seem 
right. (Especially since the A -> trunk and trunk -> A merges are done 
by different people.)

The thing is, I am pretty sure this used to work: we just left off the 
-b flag. But now svnmerge has gotten "smarter" about reflective merges 
and it's impossible to not specify -b any more. Is there a 
--no-bidirectional or something?

Thanks,

Reid