[Svnmerge] overzealous exclusion of reflective merges?

[Dustin J. Mitchell]

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.

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com