Orcas Merge Enhancements

tfsvcs — Tue, 22 May 2007 15:42:00 GMT

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.

Namespace conflicts while Merging

tfsvcs — Wed, 04 Apr 2007 01:28:00 GMT

I thought I would talk about namespace conflicts while merging. A namespace conflict occurs when 2 items try to occupy the same slot in the tree. The main reasons for namespace conflicts during merge are:

- Items with the same name are created in 2 branches without a merge relationship established between them, below is an example which involves a baseless merge.
tf merge /baseless branch branch2 /r (if file.txt was added in branch, it gets branched to branch2)
tf checkin /i
tf merge branch trunk /r (file.text gets branched up to trunk)
tf checkin /i
tf merge branch2 trunk /r (since there is no merge relationship for file.txt in trunk, it gets branched to trunk)

- Another example would be if the same file was added and checked into 2 related branches.

Now that this has occurred how would you go about resolving a namespace conflict:

(assume 1.txt was added and checked in both to trunk and branch):

D:\temp_Dd\ws113>tf merge trunk branch /r
merge, branch: $/proj/trunk/1.txt;C13 -> $/proj/branch/1.txt

D:\temp_Dd\ws113>tf checkin /i
branch:
Checking in merge, branch: 1.txt
Conflict: The item $/proj/branch/1.txt already exists.

TF10141: No files checked in: resolve the conflicts and try again.

1. If the 2 items are not related, you have the option to keep your changes and rename the file in the branch out of the way. This basically moves the existing item out of the way:

D:\temp_Dd\ws113>tf resolve branch\1.txt /auto:AcceptYoursRenameTheirs /newname:branch\2.txt
Resolved D:\temp_Dd\ws113\branch\1.txt as AcceptYoursRenameTheirs
D:\temp_Dd\ws113\branch:
Getting 2.txt

D:\temp_Dd\ws113>tf status
File name Change        Local path
--------- ------------- -------------------------------------------------------
$/proj/branch
1.txt     merge, branch D:\temp_Dd\ws113\branch\1.txt
2.txt     rename        D:\temp_Dd\ws113\branch\2.txt

2 change(s)

2. If the 2 items are related - your best option would be to undo the change and establish a relationship using /baseless. This will ensure that future merges will proceed smoothly:

D:\temp_Dd\ws113>tf merge trunk branch /r /baseless

I hope to blog soon about some improvements we have made in Orcas to improve the experience around this case.

Chandru

Team Foundation - Version Control Server Team : Conflict

Orcas Merge Enhancements

Namespace conflicts while Merging