Looking at the list of revisions involved I would:
- Revert any merges you have have already committed.
- Merge the branch with revs 27 to 68 into the branch with revs 5 to 80.
- Use the "Merge a range of revisions" option.
- Use the "specific range" option and "Show Log" to select one or
more revisions to apply, starting from the earliest ones.
- If the merge comes up with conflict errors, you can cancel, revert,
and try again with smaller batches of revisions.
- Merge the branch with revs 5 to 80 into trunk.
Hope that helps
Tony
On Friday, 18 June 2021 at 21:22:19 UTC+10 [email protected] wrote:
> 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/fb5f2df3-4346-4595-a522-57d9f672081cn%40googlegroups.com.
