ChandruR's Blog

Creating partial branches in TFS

chandrur — 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

chandrur — 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

chandrur — 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

chandrur — 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 Beta1 (subject to change)

tbl_VersionedItem                    16 + (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

chandrur — 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..

chandrur — 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