ChandruR's Blog

TF203028 and TF203071 errors with branches in TFS 2010

Chandru - MSFT — Sat, 04 Dec 2010 20:09:28 GMT

In this post, I am going to dig a bit deeper into the TF203028 and TF203071 errors. To give you some background we introduced the concept of “branch roots” in TFS 2010, which have the following properties:

1. They are identified by a path in version control.

2. In order to track a changeset, there must be a branch defined which encompasses changes in the changeset.

3. You cannot nest them, the reason for this is the visualizations goes through the changeset and identifies the list of branches it belongs too. If you had a nested list, e.g. $/proj/trunk, $/proj/trunk/branch1 – its ambiguous which branch the changes belong too.

4. We still support the pre-2010 branching of folders / files and you can nest those.

Now to the errors:

TF203028: You cannot create a branch at {path} because a branch already exists at {sub path}.

You see this message when a branch root exists at a sub path of the folder you are trying to mark as a branch root.

In the case a sub-folder was incorrectly marked as a branch root, you can recover easily from this by converting the branch root back to a folder , from the File->Source Control->Branching & Merging->Convert to Folder menu.

TF203071: The operation cannot be completed because the source folder that you specified contains a branch. If you want to perform this operation on the branch, then you must specify {path} as the source of the operation.

This occurs when you try to create a branch from a folder and there is a “branch roots” below this.

The reason for this restriction is consider the scenario, I have the following tree structure:

$/proj/MyProduct/Branches – regular folder

$/proj/MyProduct/Branches/v1.1 – regular folder

$/proj/MyProduct/Branches/v1.1/Dev - branch root

$/proj/MyProduct/Branches/v1.1/Test - branch root, related to Dev

$/proj/MyProduct/Branches/v1.1/Release - branch root, related to Test.

Users were branching v1.1 to v1.2, hoping that the relationship between Dev->Test->Release is maintained. However the relationship being established ends up being:

$/proj/MyProduct/Branches/v1.1/Dev -> $/proj/MyProduct/Branches/v1.2/Dev

$/proj/MyProduct/Branches/v1.1/Test –> $/proj/MyProduct/Branches/v1.2/Test $/proj/MyProduct/Branches/v1.1/Release –>$/proj/MyProduct/Branches/v1.2/Release

To prevent users from making this assumption, we have the restriction. If you hit this message, you have a choice:

a. You are in the scenario described above, in that case you can setup your branches by branching $/proj/MyProduct/Branches/v1.1/Dev -> $/proj/MyProduct/Branches/v1.2/Dev and then branching -> $/proj/MyProduct/Branches/v1.2/Dev -> $/proj/MyProduct/Branches/v1.2/Test ->$/proj/MyProduct/Branches/v1.2/Release

b. If you still want to proceed with the operation (this is likely because $/proj/MyProduct/Branches/v1.1/Dev was incorrectly marked as a branch root). You can do so by converting the “branch root” back to a folder, from the File->Source Control->Branching & Merging->Convert to Folder menu.

Chandru

Orphaned locks in TFS

Chandru - MSFT — Tue, 21 Sep 2010 21:43:00 GMT

We recently found a bug which exists in TFS 2005, 2008 and 2010 where a certain set of user actions can cause you to end up with orphaned locks in a workspace. The error message you get when you try to checkout is:

The item $/proj/xyz is locked for check-out by (null) in workspace (null).

We will be fixing this bug in the next available opportunity, but until then you can use the following script to clear the locks if you hit this problem.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
DELETE l
FROM tbl_Lock l
LEFT JOIN tbl_PendingChange pc
ON l.PendingChangeId = pc.PendingChangeId
WHERE pc.PendingChangeId IS NULL

Sorry for the incovenience,

Chandru

Renaming branches in TFS 2010

Chandru - MSFT — Wed, 09 Jun 2010 21:45:00 GMT

With the switch over to slot mode in TFS 2010 renaming branch roots can lead to situations where the next merge from the renamed branch to related branches will generate more than necessary conflicts. The reason for this is that when you rename the root of a branch, the source of the rename is considered out of scope of the merge - hence we do not consider the merge history of the source name - so items where the content differs between the source and target since the last merge will be baseless merged. Below is an example which demonstrates this behavior:

REM CREATE A FOLDER WITH 2 FILES

C:\temp_dd\ws\test4>md source

C:\temp_dd\ws\test4>echo 1 > source\1.txt

C:\temp_dd\ws\test4>echo 2 > source\2.txt

C:\temp_dd\ws\test4>tf add source /r
source

source:
1.txt
2.txt

C:\temp_dd\ws\test4>tf checkin /i
Checking in add: source

source:
Checking in add: 1.txt
Checking in add: 2.txt

Changeset #14 checked in.

REM BRANCH THE FOLDER

C:\temp_dd\ws\test4>tf branch source target
target

target:
1.txt
2.txt

C:\temp_dd\ws\test4>tf checkin /i
Checking in branch: target

target:
Checking in branch: 1.txt
Checking in branch: 2.txt

Changeset #15 checked in.

C:\temp_dd\ws\test4>tf edit target\1.txt
target:
1.txt

REM EDIT A FILE IN THE TARGET BRANCH

C:\temp_dd\ws\test4>echo "line added in target" > target\1.txt

REM EDIT A FILE IN THE SOURCE BRANCH

C:\temp_dd\ws\test4>tf edit source\1.txt
source:
1.txt

C:\temp_dd\ws\test4>echo "line added in source" > source\1.txt

C:\temp_dd\ws\test4>tf checkin /i
source:
Checking in edit: 1.txt

target:
Checking in edit: 1.txt

Changeset #16 checked in.

REM MERGE THE EDIT FROM THE SOURCE BRANCH TO THE TARGET BRANCH. RESOLVE THE CONFLICT BY KEEPING BOTH LINES

C:\temp_dd\ws\test4>tf merge source target /r
Conflict (merge, edit): $/proj/test4/source/1.txt;C16~C16 -> $/proj/test4/target/1.txt;C16

C:\temp_dd\ws\test4\target\1.txt: 0 local, 0 server, 0 both, and 1 conflicting
Resolved C:\temp_dd\ws\test4\target\1.txt as AutoMerge

C:\temp_dd\ws\test4>tf checkin /i
target:
Checking in merge, edit: 1.txt

Changeset #17 checked in.

REM RENAME THE SOURCE BRANCH

C:\temp_dd\ws\test4>tf rename source source2
source2

source2:
1.txt
2.txt

C:\temp_dd\ws\test4>tf checkin /i
Checking in rename: source2

Changeset #18 checked in.

REM MERGE AGAIN FROM THE RENAMED BRANCH TO THE TARGET BRANCH

C:\temp_dd\ws\test4>tf merge source2 target /r
Conflict (merge, edit): $/proj/test4/source2/1.txt;C18~C18 -> $/proj/test4/target/1.txt;C17
merge: $/proj/test4/source2;C18~C18 -> $/proj/test4/target;C15
merge: $/proj/test4/source2/2.txt;C18~C18 -> $/proj/test4/target/2.txt;C15

As you can see source2\1.txt shows up as a merge-edit conflict, however source2\2.txt just has a merge on it (to update merge history) - since the content between the last merged versions are the same. In this case the conflict auto-merges well, but it might not in certain cases.

So my recommendations for this case:

1. Avoid renaming branches - a cleaner solution would be to, at the right point in your release merge all changes to a parent branch and then re-branch to create a new branch hierarchy.

Or for the brave of heart :)

2. You will need to time the rename of your branch, to a point in your release where you can merge to all related branches. The steps to follow are:

a. Merge all changes from the branch you wish to rename to all related branches, check in these merges.

b. Rename the branch and checkin the rename.

c. Re-merge to all related branches

d. Look at any items which have a merge, undelete from step c). Undo the merge on them and re-merge using /discard. e.g. if $/proj/target/1.txt has a merge, undelete on it

tf undo $/proj/target/1.txt

tf merge /discard $/proj/source-rename/1.txt $/proj/target/1.txt

e. For any remaining conflicts - resolve them as KeepTarget. The reason this is safe to do, is that you have already merged all changes to the target branch in step a)

Chandru

Improved merge conflict handling in TFS2010

Chandru - MSFT — Fri, 23 Apr 2010 19:06:00 GMT

Hello,

It's been a while since my last post - the dust from the RTM release has settled and I hope to get back to blogging regularly. In this post I plan to talk about some of the changes we made to reduce the # of merge conflicts you will get.

1. Rename / Undelete roots are no longer conflicts - in TFS 2005/2008 all renames, undeletes were conservatively marked as conflicts. This is no longer the case. Renames / Undeletes will be merged automatically.

C:\temp_dd\ws\testing>tf rename main\file.cs main\file-rename.cs
main:
file-rename.cs

C:\temp_dd\ws\testing>tf checkin /i
main:
Checking in rename: file-rename.cs

Changeset #66 checked in.

C:\temp_dd\ws\testing>tf merge main feature /r
merge, rename: $/proj/testing/main/file-rename.cs;C66~C66 -> $/proj/testing/feature/file.cs;C65

2. In a previous post I had talked about how a resolution of keep yours / accept merge in 1 direction would result in a conflict in the opposite direction. We have changed the default behavior so these are auto-resolved.

C:\temp_dd\ws\testing>tf merge main feature /r
Conflict (merge, edit): $/proj/testing/main/file-rename.cs;C68~C68 -> $/proj/testing/feature/file-rename.cs;C68

C:\temp_dd\ws\testing>tf resolve /auto:keepyours
Resolved C:\temp_dd\ws\testing\feature\file-rename.cs as KeepYours

C:\temp_dd\ws\testing>tf checkin /i
feature:
Checking in merge: file-rename.cs

Changeset #69 checked in.

C:\temp_dd\ws\testing>tf merge feature main /r
merge, edit: $/proj/testing/feature/file-rename.cs;C68~C69 -> $/proj/testing/main/file-rename.cs;C68

If you want the old behavior, there is a flag to instruct the merge engine to be conservative about resolving such conflicts:

C:\temp_dd\ws\testing>tf merge feature main /r /conservative
Conflict (merge, edit): $/proj/testing/feature/file-rename.cs;C68~C69 -> $/proj/testing/main/file-rename.cs;C68

So that leads to the question, what are the conflict rules for 2010:

a. A file has a change (edit, rename, encoding, delete, undelete) both in the source and target

b. The merge is baseless, and you are propagating a change (edit, rename, encoding, delete, undelete)

c. You are merging from a point which is not the point of your last merge. An example of this is a cherry pick merge.

C:\temp_dd\ws\testing>echo 44444 >> main\file-rename.cs

C:\temp_dd\ws\testing>tf checkin /i
main:
Checking in edit: file-rename.cs
Changeset #71 checked in.

C:\temp_dd\ws\testing>echo 5555 >> main\file-rename.cs

C:\temp_dd\ws\testing>tf checkin /i
main:
Checking in edit: file-rename.cs

Changeset #72 checked in.

C:\temp_dd\ws\testing>tf merge main feature /r /version:c72~c72
Conflict (merge, edit): $/proj/testing/main/file-rename.cs;C72~C72 -> $/proj/testing/feature/file-rename.cs;C69

This simple example often throws people off and here is why: The reason is that all content merging in TFS is done on the client, the server only handles simple conflicts, in this case the resolution of the conflict requires creation of new content (i.e. a file without lines 44444 in it and only 5555 in it). The mechanism we have to resolve this is to file a conflict and let the client merge tool handle it.

Happy Merging,

Chandru

Creating partial branches in TFS

Chandru - MSFT — Thu, 16 Jul 2009 19:00:00 GMT

One of the less known features in TFS is the ability to create partial branches. A partial branch is where you create a branch with only a set of subtrees of the source branch. There are a number of reasons why you might want to do it, including saving disk space on the server, saving time on merging, etc.

The reason it is not a very visible feature, is that it is enabled by the fact that branch / merge command respect your target working folder mappings.

To create a partial branch:

C:\TEMP\ws>tf dir trunk /r
$/proj/trunk:
$dev
$qa

2 item(s)

The next part is a bit non-intuitive as you need to cloak out the path in target space, even though it doesn't exist as yet:

C:\TEMP\ws>tf workfold /cloak branch\qa

C:\TEMP\ws>tf branch trunk branch
branch

branch:
dev

C:\TEMP\ws>tf checkin /i
Checking in branch: branch

branch:
Checking in branch: dev

Changeset #7 checked in.

Keep in mind that you must have the mappings in every workspace you use to merge, as not having them will cause the branch to convert to a full branch as shown.

C:\TEMP\ws>tf merge trunk branch /r
There are no changes to merge.

C:\TEMP\ws>tf workfold /decloak branch\qa

C:\TEMP\ws>tf merge trunk branch /r
merge, branch: $/proj/trunk/qa;C6 -> $/proj/branch/qa

Cheers

Resolving merge content conflicts as KeepYours / AutoMerge

Chandru - MSFT — Thu, 02 Jul 2009 19:57:00 GMT

I get this question, fairly often "I just merged from Trunk -> Branch, resolved all conflicts and checked in. I now merge from Branch -> Trunk, and there are no changes in trunk, so I expect no conflicts, but I get conflicts - why?". The short answer is you will get conflicts on any files you had conflicts on in the merge from Trunk -> Branch and resolved as KeepYours or AutoMerge. The reason for this is that different branches have different purposes, so a resolution of a conflict in 1 direction, doesn't automatically imply the same resolution in the reverse direction. Consider the following scenario:

CS	Change	Comment		CS	Change	Comment
Development				Servicing
10	Add	Added file
			=>	20	Branch	From Development
30	Edit	Fixed Bug 1 + refactored code
				40	Edit	Fixed bug 2
			=>	50	Merge, Edit	Merge from Development, discarded refactoring took bug fix

In changeset 50, you accepted a bug fix from Development, but discarded a refactoring which was not needed for servicing. Now you want to push back change 40 to the Development branch. In this case, you don't want to blindly accept the Servicing version of the file, hence we present you with the opportunity to choose content coming back to Development. TFS mechanism of doing this is filing a conflict. The same reasoning is applied for the KeepYours case.

Hope that helps explain things, when you do hit this scenario.

Cheers,

Chandru

Team Foundation Server Performance - SQL Server Configuration Settings

Chandru - MSFT — Tue, 23 Jun 2009 17:25:00 GMT

I would like to preface this article by saying that for the most part SQL Server requires few changes to the default configuration. However below is a list of potential SQL Server configuration changes, which I have seen help performance on large TFS installations (including our very own devdiv server). I can't guarantee that all / any of them might be applicable to your environment - so the general guidline is if it ain't broke, don't fix it :)

Memory

32 bit servers

If you have a dedicated SQL Server with more than 4gb of RAM - you want to enable AWE. AWE allows a 32 bit OS to address more than 4GB of ram. Instructions to enable AWE can be found at: http://msdn.microsoft.com/en-us/library/ms190673.aspx

64 bit servers

If you are experiencing frequent paging of SQL Server's buffer pool by the OS - you want to enable lock pages in memory. Details on how to detect this is happening and correct it can be found @ http://support.microsoft.com/KB/918483/EN-US

TempDB

I had covered TempDB configuration in a previous blog post of mine, these changes will help almost any TFS installation

Lock Escalation

The general symptom here is, one user has a large checkin (over 5000 items) running - while this is occurring, other users are blocked from checking out files, and doing other version control operations. This is due to a feature called lock escalation where SQL converts finer grain locks into a more coarse lock to curb the memory utilized by locks. If large checkins are a frequent part of your process and you have a 64 bit server you can disable lock escalation. If you have a 32 bit server and want to utilize this option trace flag 1224 (rather than trace flag 1211) is a safer option.

CPU Parallelism

a. You have a multiprocessor server

b. Run the following query - if you notice CXPACKET high on the result list - it is generally indicative of waits due to parallelism (queries utilizing multiple cpus). Keep in mind the value is in milliseconds and is cumulative since server restart:

SELECT top 10 wait_type, wait_time_ms - signal_wait_time_ms as wait_time

FROM sys.dm_os_wait_stats

WHERE wait_time_ms > 0

ORDER BY wait_time_ms - signal_wait_time_ms DESC

If you frequently see CXPACKET as a wait type, you might want to consider reducing the max degree of parallelism on your server. There isn't really a fixed # you should set this to, and you would need to experiment a bit with your workload to get the right mix. If you do choose to change this setting, my general advice would be to start higher rather than lower.

EXEC sp_configure 'show advanced options', 1

RECONFIGURE

EXEC sp_configure 'max degree of parallelism', <replace with max # of cpus per query>

RECONFIGURE

Space used by TFS branches

Chandru - MSFT — Wed, 10 Jun 2009 00:37:00 GMT

This seems to be a common enough question to warrant a post. "I am branching a folder with 30gb of content" - how much space will it add to my database. As you might probably already know, a TFS branch creates only new metadata rows for the target paths, hence the size of the files are irrelevant. There is a fixed* space occupied by each item you branch. Below is roughly how the space is broken up:

TFS 2008

tbl_VersionedItem                          25 bytes
tbl_Namespace                             24 bytes + (avg path length * 2 * 2) bytes
tbl_MergeHistory                           80 bytes
tbl_Version                                   56 bytes + (avg path length * 2 * 3) bytes
Total                                            185 bytes + (avg path length * 10) bytes

TFS 2010 RTM

tbl_VersionedItem                  8 + (avg path length * 2 * 2) bytes
tbl_MergeHistory                    52 bytes
tbl_Version                             56 bytes + (avg path length * 2 * 3) bytes
Total                                      124 bytes + (avg path length * 10) bytes

In TFS 2010 - if you have SQL Server 2008 Enterprise edition, we enable compression on the tables with paths in them. In our tests this has shown a ~3x IO saving in large trees.

Do keep in mind that this doesn't include any transaction log space (or the space used by pending changes) for creation of the branch.

Cheers,

Chandru

*actually its variable and it mainly depends on how long your paths are - since paths are stored as unicode column, SQLServer needs 2 bytes to store each character in the path

Configuring TempDB for Optimal TFS Performance

Chandru - MSFT — Tue, 10 Jan 2006 20:10:00 GMT

As any complex database application would Team Foundation Server uses TempDB both explicitly and implicitly. In addition the Version Control component will use Read Committed Snapshot Isolation (RCSI) in RTM for improved concurrency. RCSI is a new feature to Yukon and provides a mechanism for readers to read committed changes without having to take a shared lock on the data. In doing so however it stores changed rows for active transactions in its version store (TempDB). This further emphasizes the need for an optimally configured TempDB. So here are some pointers found during our testing:

1. Manually grow TempDB - file growth can be expensive and time consuming. SQL Server reverts back to the original TempDB size upon re-start - thereby you incur the cost again after every restart. I suggest manually growing the data file to approx. 20% of all the TFS databases. This also will prevent file fragmentation if there are multiple files on the same drive.

2. Use multiple equal sized data files - if you are using a multi-processor data tier, use N equal sized data files (when N is the # of processors, the sum of all the data files can equal 20% of all your databases). This will allow SQL Server to allocate extents in a round robin fashion and reduces contention. If you have a dedicated drive for tempdb with more than adequate space assigned - turn off auto-growth to prevent the data files from unevenly growing and interfering with the round robin allocation. If you do choose to turn off auto-growth make sure that you have allocated enough space to tempdb to prevent it from running out of space.

Ofcourse - dedicated (or faster) drives for tempdb will help too....

A bit about me..

Chandru - MSFT — Fri, 30 Dec 2005 22:56:00 GMT

Greetings! This being a slow week is a perfect time for me to start my blog. My name is Chandru Ramakrishnan - I'm a Software Design Engineer (SDE) with Visual Studio Team Foundation Server. I've been with the group since Aug 05 and primarily work on the data and application tiers of the product. I am sure you already know about TFS - so I will skip the intro :)(http://msdn.microsoft.com/vstudio/teamsystem/)

History:
Prior to Microsoft, I spent the last 4.5 years at art.com - through which I held a number of different roles (Architect, Developer, DB guy). I spent my time there working on their website and back end ERP style apps.

What will I be blogging about:

I hope to begin soon by blogging some perf tips to keep your TFS running optimally - starting with SQL Server (been working with it since '99) and other pointers.

Until then...Happy New Year!

-Chandru