Team Foundation - Version Control Server Team : Orcas

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.

New CommandLine Option for Branch in Orcas

tfsvcs — Thu, 10 May 2007 17:09:00 GMT

In Orcas we have added an additional option to the branch command which gives the user a fast way to create a branch without having to download any of the files or get operations locally. The option is /silent and instructs the server to not send back any get operations. Ofcourse this means you will not see the scrolling list of files and there will be no status until the command completes.

To use it:

D:\temp_dd\ws>tf branch src tgt /silent

D:\temp_dd\ws>tf status
File name Change Local path
--------- ------ --------------------------------------------------------------
$/proj
tgt branch D:\temp_dd\ws\tgt

$/proj/tgt
1.txt branch D:\temp_dd\ws\tgt\1.txt

2 change(s)

We have found it very useful for our large devdiv branch creations.

Cheers,

Chandru

P.S. The usual caveat applies that this might change before Orcas ships.

Orcas Workspace Mapping Improvements

tfsvcs — Thu, 28 Dec 2006 23:52:00 GMT

I thought I would give you an overview of the workspace mapping improvements which Brian Harry mentioned in his TFS roadmap post. Please do keep in mind that any of this might change / be removed before Orcas ships - so there are no guarantees.

History: In DevDiv our branches are enormous , a developer typically maps only portions of the tree they need to work on. Upon analysis we determined an average workspace had 100+ mappings. To reduce the performance and maintenance overhead of a large number of mappings we are introducing the following features.

1. Mappings under Cloaks

This will allow you to cloak a top level folder and map individual folders beneath it.

e.g. Cloak $/proj/privatedirs

Map $/proj/privatedirs/johndoe d:\dd\privatedirs\johndoe

2. One Level Mappings

This will allow you to map all immediate child items of a folder (any sub folders & items will not be mapped locally)

e.g.

$/proj/dir/

$/proj/dir/file1.txt

$/proj/dir/file2.txt

$/proj/dir/dir2

$/proj/dir/dir2/file2.txt

A one level mapping, will end up getting only the items under $/proj/dir (i.e. file1.txt, file2.txt, dir2 will be created - but no items below it will be downloaded)

Map $/proj/dir/* d:\dd\dir

These features will allow for more complex workspace definition, and allow users to cloak out larger portions of the tree they do not need (improving get performance)

Cheers,

Chandru