On Fri, Jun 6, 2008 at 4:47 PM, Reid Priedhorsky <[EMAIL PROTECTED]> 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 _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
