[Svnmerge] overzealous exclusion of reflective merges?

[Blair Zajac]

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.

The svn merge --reintegrate feature in 1.5 should handle the conflict issue with 
merging back to trunk.

Blair