Orcas Merge Enhancements
Based upon customer feedback(both external and internal), we have made a number of improvements to the merging experience in Orcas. Below are some of the most significant changes:
1. I described how to handle namespace conflicts while merging in my previous blog (Namespace conflicts while Merging). We have changed the default behavior to automatically perform a baseless merge between items with the same relative name in the trees, which have no merge relationship with any other items in the 2 trees. Therefore in my previous example, 1.txt in trunk will be merged to 1.txt in branch.
merge: $/proj/trunk/1.txt;C13 -> $/proj/branch/1.txt
There will be no conflict during checkin and no need to perform baseless merges at a file level.
2. No conflicts will be filed for baseless merges where the files in the source and the target are the same. We detect this on the server using the file hash, therefore unfortunately for clients which have FIPS enabled this will not work. This should help in reducing the overall number of conflicts filed in baseless merges.
3. Improved the conflict detection algorithm to file conflicts in cases where edits are merged after merging recursive changes (renames, deletes, undeletes) on a parent folder.
4. Enabled merging from a deleted source root item to a related target using the deletionId e.g. The following will be an example for merging a deletion of a file from source to target.
tf merge $/proj/source/a.txt;X20 $/proj/target/a.txt
5. Ability to execute a merge on a child folder and then execute a merge on a parent folder with the merge on the child folder still pending. The server will simply not attempt to remerge the items which have already been merged e.g.
tf merge $/proj/src/folder $/proj/tgt/folder /r /version:C1~C500
.
.
.
tf merge $/proj/src $/proj/tgt /r /version:C1~C500
This will work seamlessly if you have the version range pinned down for botrh merges.
6. Fixed merge bugs, the most notable being:
a. AcceptTheirs does download file at end range of merge when a later changeset has already been merged previously. This occurs when a user merges an edit e.g. changeset 100 (tip) without merging over a previous edit changeset 90. If the user runs a catch up merge to tip and then tries to resolve a conflict as AcceptTheirs it will download the file as of changeset 90 as opposed to changeset 100.
b. User is unable to merge changes to the target branch if there is another deleted branch with the same name and a rename of a file has ocurred in the target. The TF14087: Cannot undelete “insert your file name here” because not all of the deletion is being undeleted error :).
Cheers,
Chandru
P.S. The usual disclaimer applies that this might change before Orcas ships.