Bruce and Stefan ,Thank you guys For the detailed guidance .. ill let you know how it goes...
Thanks again for the help On Wednesday, 16 June 2021 at 23:00:43 UTC+5:30 Bruce C wrote: > 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/ea2497fc-2567-4201-9edc-6427861990fen%40googlegroups.com.
