Branching and merging are at the heart of version control. The obvious source of information is the Subversion Red Book, specifically chapter 4 ( http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html). That describes the process, although the specifics use the SVN command line for the examples, rather than TortoiseSVN GUI instructions.
The general process is as follows: 1. Create a branch 2. Make changes as a series of branch commits 3. Regularly merge changes from the parent (often trunk) to detect conflicts around the time that they arise. These merges are often described as "update merges". Conflicts shouldn't arise often because developers would normally ensure that they're not making changes to the same code that another developer is also changing. If the conflicts are in the same file but don't overlap (as far as the diff tool can determine) then they will automatically be resolved. [The magic of version control.] However, if the changes overlap the same code*, then the conflict will require some thought of the code to resolve. 4. Repeat previous 2 steps as required 5. Perform a final update merge. Note that this causes the branch to includes the branch changes plus all the changes to trunk. This is exactly what you want trunk to be when the branch changes are included.] 6. Merge the branch back to trunk. This is often described as a reintegration merge. Note that this should not raise any conflicts as they will have been resolved when the branch was being updated, with the final update merge. 7. Delete the branch. This is no longer required now that the changes are included in the trunk. Note that the branch continues to be available in the Subversion history, but that's a different subject that you can investigate at some other time. ** The following example is a classic conflict. The original code has the line "myVar = 1". A branch is created. Subsequently, a developer commits a change to trunk that changes the line to "myVar = 2". A separate change is committed to the branch that changes the line to "myVar = 3". When an update merge is performed on the branch (to bring the trunk changes to the branch), the merge reports a conflict that the line has changed in both the trunk and the branch. There's no way for the merge process to know whether the merged code should use the trunk change (setting the value to 2) or the branch change (setting the value to 3). The developer performing the merge has to make that decision manually, typically after discussing it with the other developer.* So, what does this mean for you? Well, the following steps need to be performed: 1. Checkout the first branch. 2. Merge the changes from trunk to this branch checkout (update merge for first branch), resolving any conflicts that might arise. 3. Commit the update merge for the first branch. [Note that the HEAD of the first branch now includes the changes to the first branch plus the changes to trunk. This is exactly what you want trunk to be.] 4. Separately checkout (or switch to) trunk 5. Merge the first branch to this trunk checkout (reintegration merge). There should be no conflicts as those will have already been resolved in the branch. 6. Commit the reintegration merge of the first branch to trunk. 7. Delete the first branch. 8. Checkout (or switch to) the second branch. 9. Merge the changes from trunk to this branch checkout (update merge for second branch), resolving any conflicts that might arise. 10. Commit the update merge of the second branch. [Note that the HEAD of the Second branch now includes the changes to the second branch plus the changes to trunk, including the changes from the first branch. This is exactly what you want trunk to be.] 11. Separately checkout (or switch to) trunk 12. Merge the second branch to this trunk checkout (reintegration merge). There should be no conflicts as those will have already been resolved in the branch. 13. Commit the reintegration merge of the second branch to trunk. 14. Delete the second branch. All done. Now, where you are likely to get issues is the conflicts that arise from the merging. If the developers have not been careful, there may be overlapping code that needs manual resolution. This is something that is specific to your codebase and needs to be addressed by you. The normal practice is to think ahead to avoid conflicts or at least detect them early to resolve while it is fresh in the mind of all those involved. If this hasn't been done, then these conflicts are the results and effort will be required to overcome this. You raised a specific query. Specifically, when you merge the changes from branch 1 (by Developer 1) to trunk, it is deleting files that were reintegrated into trunk from branch 2 (by Developer 2). Do the changes in branch 1 include deletion of that file (that was separately changed in branch 2)? If so, that's a conflict right there, that needs to be resolved. Developer 2 wanted to change the file but Developer 1 wanted to delete it - it isn't possible for Subversion to determine whether the overall developer preference is to change the file or delete it. Hope this helps. On Tuesday, 15 June 2021 at 17:27:10 UTC+1 Stefan wrote: > On Tuesday, June 15, 2021 at 12:44:58 PM UTC+2 [email protected] wrote: > >> Hello everyone , >> >> >> I am facing an issue when i am trying to merge the changes of two >> branches into the trunk. >> >> We had created two seperate branches from the trunk for two seperate >> features for developement . ( Please see the attached picture). >> >> Developer 1 worked uptill rev 68 and left our organisation. while dev 2 >> continued uptill 80. Someone merged the Developer 2 with the trunk and did >> a commit. We are trying bring the changes of Developer 1 to the trunk but >> not able to do so. It deletes the files created by the Developer 2 while >> doing the merge . Can some one guide me the exact process >> I know this is a silly question , but i have gone through the svn book >> but cannot make anything out of it. >> >> The merge process which i follow. isswitch the working copy to trunk and >> use merge two differnt trees . and merge from the trunk to the developer 1 >> branch. >> > > No, don't merge trees. Use the "merge a range of revisions" option in the > merge dialog, then select the revisions of the branch that dev1 created > (27-68) onto trunk. > > -- You received this message because you are subscribed to the Google Groups "TortoiseSVN" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/ed51a799-4a2d-4914-96e6-f4a88296f0c0n%40googlegroups.com.
