Dustin J. Mitchell wrote: > 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.
The svn merge --reintegrate feature in 1.5 should handle the conflict issue with merging back to trunk. Blair _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
