On 2/28/07, Raman Gupta <[EMAIL PROTECTED]> wrote: > golan davidovits wrote: > > The reproduction is simple. Just change same line of a file both on > > Trunk and Branch run svnmerge.py merge (Trunk2Branch) and resolve > > the conflict by selecting "mine" via editor (such Tortoise). When > > you merge back to Trunk you will still get the conflict. For > > example: > > > > Trunk -> "Trunk line" Branch -> "Branch line" I resolved the > > conflict by selecting "Branch line" Then merged back to Trunk and > > still got the same conflict Trunk -> "Trunk line" Branch -> > > "Branch line" > > Hmmm, when you use the bidirectional flag, the revision in which you > resolved the conflict is ignored (which note that, despite this > situation, normally prevents conflicts). Therefore, it seems that the > conflict will have to be resolved manually for both merges. > > I'm not sure that, with the current design of svnmerge, this can > really be fixed. I wonder if the merge support in svn 1.5 will handle > this better?
I ran into (I think) the same problem. The doc I found via Google suggested this (which I wrote up at http://bcfg2.org/wiki/Bcfg2SubversionHowto): ==== Merging trunk into branch after merging branch into trunk ==== I may just be doing something wrong, but I ran into this problem after merging a branch into the trunk, and then going back to the branch to merge trunk into that branch: $ cd branch $ svnmerge.py merge $ svn ci -F svnmerge-commit-message.txt Trying to add new property 'svnmerge-integrated' with value 'xxx' but property already exists with value 'yyy'. Reason: svnmerge.py tried to copy all properties (and merging info) from the trunk onto the branch. You can resolve the root as is (it will keep branch values) by issuing: svn resolved . And then again issuing: $ svn ci -F svnmerge-commit-message.txt -- Daniel Clark # http://dclark.us # http://opensysadmin.com _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
