I have read a lot and lot on this but couldn't figure out what theissue is, and it's pretty weird. I am using version 1.7 for serverand latest tortoise version (1.7) for the client. Here's thescenario:
I created a parent branch, and then created 1 child branch from it.So, PARENT_BRANCH -> CHILD_BRANCH
Add a new directory in CHILD_BRANCH and commit.
Using tortoise merge all changes from CHILD_BRANCH toPARENT_BRANCH. I used 'merge a range of revisions' option anddidn't specify any revisions in the option, so basically let svnidentify and manage the revisions to merge.
After the merge, the new directory is created inPARENT_BRANCH.
Merge back from PARENT_BRANCH -> CHILD_BRANCH.
I get tree conflict on the new directory, with the error that thedirectory its trying to add is already there.
Well, of course the directory is there in child branch as that'swhere it originally came from. I though that svn 1.5+ tracks mergesusing merge-info, and should have known this is the branch fromwhere the directory came and should not throw the tree mergeerror.
Any idea what's going on and how can I fix this? The example I gaveis just for 1 directory, but in reality there are lots ofdirectories and files, so going one by one manually takeshours.
The problem is that both CHILD and PARENT have different revisionswhich added the same folder. CHILD doesn't have any knowledge ofthe revision in your step 4.
Immediately after every merge from CHILD to PARENT (your step 4.)you need to record against CHILD that it has the revision of themerge from CHILD to PARENT. You do this by merging that revision inPARENT to CHILD and checking this flag in tortoisesvn:
Have a read of this post on subversionbranch reintegration.
Thanks forthe response. So if I understand it correctly, if let's say whilemerging from CHILD->PARENT, svn identifies r100-r200 will betaken and merged from CHILD. Post merge, when I commit, lets say itwas revision
r201. So, now I have to tell CHILD to record r201 as"record only" so that when I merge back from PARENT->CHILD, thisparticular revision will be ignored and I should not get any treeconflicts arising because of CHILD->PARENT->CHILD merge. It'sreally strange,
since svn should know that already as to whichbranch originated the create directory command in the firstplace.
a branch topic intothe trunk repeatedly:Do
the following onevery
merge --reintegrate , as you would normally.(
merge --record-only -c M ^/. Notethe
Step 2 essentially tells the topic branch to consider the mergecommit (revision
step 1) part of its history. This merge-revision is the onethat usually causes problems during reintegration; svn tries toundo rM whenintegrating topic asecond
So, repeated reintegration works, justnot automatically. :)
I eventually found this solution throughan enlighteningcommit message to the svn source and thematching test (searchfor
"def multiple_reintegrates"). This is a "clever trick"discovered and used by svn-devs with the current releases. It'seven been added to morerecent
documentation. The result is still not as good as aDVCS's merging properties, but it's at least functional.
The only broad downside (as per an openissue as of June 2, 2010) is that apparentlythe
-goutput is messy. I guess this is the risk.