Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

February, 2006

  • Buck Hodges

    Working around not being able to delete a work item type


    The following question came up in the forum:  "How do I delete the custom work item type that I created?"  Tony Edwards posted the following.  One other thing that comes to my mind is to have a second server to use for experimentation before applying changes to the production server.

    It is not possible in v1 [to delete work item types].  This question came up recently and Bill Essary gave the following guidance for mitigating the problem:

     Here are a few things that you can do:

     1)   Change the name of the type to something like “(Deprecated) Bug” so that users know not to use it

     2)    Add an attribute to the WIT that stops users from creating a new Work Item of that type.  If your initial workflow state is “active,” the attribute would be added to this transition

          <TRANSITION from="" to="Active" not=" "[global]\Team Foundation Valid Users">

    [Update 8/21/06]  Unfortunately, work item types cannot be renamed in v1, so #1 above is incorrect.

    [Update 4/17/09]  In TFS 2008, you can delete work items and work item types using the destroyWI and destroyWITD commands in tfpt.exe in Team Foundation Server Power Tools for 2008.

  • Buck Hodges

    Listing the process templates on a TFS server


    In response to a forum question about how to list the process templates on the server, Tony Edwards, a developer on Work Item Tracking, posted the following code snippet showing how to do it.  The TeamFoundationServer object provides a number of services, including one for dealing with process templates.

    Here is  a simple console program to list the templates.  IProcessTemplate has members that return XML - you could bind that to the grid.  You would invoke the sample below as follows:

    templateheaders http://<your_server>:8080

    using System;
    using System.Collections.Generic;
    using System.Text;
    using Microsoft.TeamFoundation.Server;
    using Microsoft.TeamFoundation.Client;

    namespace TemplateHeaders
        class Program
            static void Main(string[] args)
                TeamFoundationServer tfs = new TeamFoundationServer(args[0]);
                IProcessTemplates templates =
                    (IProcessTemplates) tfs.GetService(typeof(IProcessTemplates));
                TemplateHeader [] headers = templates.TemplateHeaders();
                foreach (TemplateHeader header in headers)

    If you haven't built a code sample before, you can find instructions on adding the TFS assemblies to the .NET tab in VS here.

  • Buck Hodges

    Want to influence the next version of TFS? Now is the time!


    Brian Harry has a new post requesting your input for the next version of TFS.  The team has just started planning for TFS, so now is the best time to let him know what you would like to have in the next version.

    Team Foundation Server and the Future

    With V1 now mostly behind us we're starting to look ahead to what comes next.  We're collecting the lists of everything we wished we had been able to V1 and all of the suggestions that we've gotten from customers - forums, email, MSDN Product Feedback Center, etc.  We're also taking a high level look at what the core value proposition(s) for our next release should be and what timeframe we should be targeting.

    We value your input very much.  We want to incorporate it at the very beginning of our planning.

  • Buck Hodges

    Determining the amount of space required to store files and work items


    Recently someone asked how to estimate the space required for the databases on a Team Foundation Server.  To do that, we can take a look at our own dogfood server to see where the space goes.  With that information and some knowledge of how the system works, we can come up with a useful way to estimate the approximate space required by the TFS databases.

    Version Control

    If we start with the version control database, we currently have 1.7 M files and folders, so that works out to about 77 KB per item (size of the version control database divided by the number of items).  That’s averaged over all of the content for all of the versions for every item ever checked into dogfood (starting point is the import of code on Dec. 10, 2004) and all of the workspace information.  You can use sp_spaceused in a SQL query window on your data tier to calculate numbers for your own server.

    If we look at just the file content table alone (tbl_Content), it’s 60 KB per item (only about 10% of the items are folders, so we'll stick with round numbers).  That leaves approximately 17 KB per item.  That 17 KB is dominated by the local version table (tbl_LocalVersion), which records what items and versions users have in their workspaces and where those items reside on the local disks.  The local version table accounts for 15 KB of that 17 KB (again taking the data and index sizes and dividing by the total number of versioned items in the repository).  So, the growth of tbl_Content and tbl_LocalVersion will account for nearly all of the growth of the version control database.

    There are 1,780 workspaces and about 1.7 M files and folders on our dogfood system.  To get those statistics for your own server, you can use the following URL, replacing "apptiername" with the name of your TFS server (application server).

    TFS 2005 and 2008:



    For TFS 2010 and newer you must also specify the name of the team project collection (replace CollectionName):


    The response will be an XML response that looks something like the following.  The QueryRepositoryInformation web service method is part of the version control administration web service.  You can more information about in the blog post, TFS Source Control administration web service.


      <?xml version="1.0" encoding="utf-8" ?>
      <AdminRepositoryInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" UserCount="88" GroupCount="9" WorkspaceCount="18" ShelvesetCount="29" FileCount="151" FolderCount="18" MaxChangesetID="33" PendingChangeCount="13" xmlns="http://schemas.microsoft.com/TeamFoundation/2005/06/VersionControl/Admin/03" />

    For stats on our own dogfood server, check out John Lawrence’s latest post (the numbers I used are based on data from the dogfood server at the time of this writing).

    Not every file and foler in the system is in every workspace.  If you take the number of rows in the local version table and divide it by the number of workspaces, you can determine the average number of files and folders in each workspace.  On our dogfood server, that works out to 27,536.

    The growth per item added to version control will depend on how many workspaces have it mapped (that’s the local version table growth) and the compressed size of each version of the item (that’s the content table).  Note that content size is further reduced because TFS stores compressed “deltas” where old versions are just the differences from later versions.

    Each new row in the local version table adds about 520 bytes (one row gets added for each workspace that gets the newly added item, and the size is dominated by the local path column).  If you have 100 workspaces that get the newly added item, the database will grow by 52 KB.  If you add 1,000 new files of average size (mix of source files, binaries, images, etc.) and have 100 workspaces get them, the version control database grows by approximately 112 MB (60 KB * 1,000 + 520 * 1,000 * 100).

    Work Item Tracking

    There are two work item databases, one for work items and one for work item attachments.  The work item attachment database on our dogfood server has lots of screenshots and log files that are associated with the work items, so it's fairly large, per item.  So, if you average it out as above, each work item uses 163 KB on average, including attachment space.  Attachment space is about 75% of the average per work item.

    Space Estimation

    Given the analysis above, it's easy to come with a formula to estimate the database space require as more items are added.

    # of files/folders * avg. content size + 520 * # of workspaces * avg. # of files in workspace + # of work items * average size of work item

    Substituting the averages from our dogfood server it, we get the following.

    # of files/folders * 60 KB + 520 * # of workspaces * avg. # of files in workspace + # of work items * 163 KB

    Substituting the current totals into the formula yields the following.

    1.7 M * 60 KB + 520 * 1,780 * 27,536 + 67,460 * 163 KB = 138.4 GB

    The actual sum of the dogfood database sizes is 173.7 GB, which includes free space in the database and additional areas, such as the warehouse, that can’t be easily counted by using the number of files, workspaces, and work items.  Dividing the actual size by the estimated size yields a factor 1.25 to account for other areas not included in the formula.


    The final space estimation formula is as follows, providing an simple way to determine approximately how much space will be required as a system grows.

    1.25 * (# of files/folders * avg. content size + 520 * # of workspaces * avg. # of files in workspace + # of work items * average size of work item)

    Brian Harry read an early version of this post and provided valuable feedback along with work item analysis and overall space usage.

    [UPDATE 8/30/07]  I've attached a spreadsheet that someone put together that is based on the final formula.

    [UPDATE 8/27/2010]  I've added the URL to get to the info for TFS 2010 and newer.  For customers using SQL 2008 Enterprise or newer, TFS uses SQL data compression, so the version control data size will be somewhat smaller than predicted here.

  • Buck Hodges

    Robert Horvick's blog posts on branch and merge history


    Robert Horvick, now a dev on the version control team, has been writing a series of posts on using the branch and merge API methods.  If you want to explore that area, I recommend checking out his posts.

    Following merge history using the TFS command line is the introductory look at what he's trying to do.  Then he walks through creating a tool to determine whose contributed what via merging.

  • Buck Hodges

    TFS MSSCCI Provider Beta 2 is available -- disable strong name validation


    As has been announced in several different blogs, the second beta of the MSSCCI provider is available, providing VS integration for users with VS 2003 and earlier (you cannot use it with VS 2005, because we provide the full experience with Team Explorer in VS 2005).

    For it to work, you will need to disable strong name validation for the beta 2 assemblies.  They are not strongly named (signed) binaries.

    If you do not disable strong name validation, you will receive two error messages.

    TFMscciSvr.exe has encountered a problem and needs to close.  We are sorry for the inconvenience.

    There was a failure while initializing the Team Foundation Server MSSCCI Provider source control provider. You cannot use this provider to perform source control operations.

    You can use the following to disable strong name validation for these assemblies, without disabling strong name validation for everything.

    Save the following text into a file called disable.reg and then type disable.reg in a Windows console command prompt to run it.

    Windows Registry Editor Version 5.00

    I have also included that as an attachment to this post, but I have called disable.txt so that your browser will allow you to download it.  When you save the file, you'll need to rename it to disable.reg.

    Of course, running this file will modify your registry, so all of the usual caveats apply.

    For those familiar with the sn command from the .NET SDK and VS installations, you can also use sn -Vr <assembly> to disable it, which is what I used to generate the registry settings.  Running sn -Vr * will disable strong name validation for all assemblies, but that means no assemblies will be checked.

    [UPDATE 2/21/06]  I've updated the registry settings here and in the attached file to disable strong name signing validation only for the assemblies used by the MSSCCI provider.

  • Buck Hodges

    Updating TFS event listeners to work with RC and RTM releases


    You may have read before about the fact that the TFS protocol version number changed between beta 3 and RC.  As a result, you have to upgrade pre-RC clients when you upgrade the server to RC or RTM (the version number for RTM should be the same as RC).

    The other thing you'll need to update is any web services that you have subscribed to TFS event notifications.  For example, I updated the Continuous Integration example code from Doug's TechEd presentation.

    In your code, you'll need to change the "02" to "03" in the SoapDocumentMethod attributes.


                            RequestNamespace = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/02")]

    New (RC and RTM):

                            RequestNamespace = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03")]
  • Buck Hodges

    Branch and merge and other useful posts

    Rob Caron pointed out a post over at Vertigo Software regarding the tf.exe command line (I like the command line too, but I'm biased :-).  There's also a nice post on branching and merging, along with quite a few other useful posts.  Check it out.
  • Buck Hodges

    List of tools and add-ins for TFS


    Richard Hundhasen mentioned that he's trying to keep a list of tools and add-ins for TFS at http://teamsystemexperts.com/widgets.aspx.

  • Buck Hodges

    Permission tool beta: One tool to set permissions for TFS, SharePoint, and Reporting


    There have been quite a few requests for a single place to set permissions in TFS, SharePoint, and SQL Reporting Services.  The Developer Aftermarket Community Solutions team in Developer Division at Microsoft just released the first beta of an administration tool for this purpose.  Kannan, the lead developer on the tool, posted the announcement(screenshot).

    Here is the description from the GotDotNet project.

    The TFS Administration Tool allows a TFS administrator to quickly add users to all three platforms utilized by TFS: TFS, Sharepoint, and SQL RS, all through one common interface. The tool also allows administrators to change the current permissions on any of the three tiers, identify any errors, and view all of the users and their permission sets across TFS, Sharepoint, and SQL RS.

    This tool was created by the Developer Aftermarket Community Solutions team in Developer Division at Microsoft.

    Please give try it and let them know what you think in the forum.

  • Buck Hodges

    Renaming folders that are explicitly mapped


    Internally, someone wanted to rename a folder and received an error instead of having the folder moved.  When trying to rename $/ProjectA/Folder1 to $/ProjectB/Folder1, the user received the error message, "TF14097: Cannot rename $ProjectA/Folder1 when it has a working folder mapping assigned to it."

    If you run into that, here's what it means.

    The system does not allow you to rename an item that is explicitly mapped.  If you bring up your workspace mappings (File -> Source Control -> Workspaces, select your workspace, and click Edit), you will see that $/ProjectA/Folder1 is listed in the mappings.  An item is mapped explicitly if you see it listed in the dialog.  An item is mapped implicitly if it’s mapped because one of its parents is listed in the mappings in the dialog.

    To rename the folder, you will need to change the mapping to map the parent, $/ProjectA, instead.  For the best experience, you may want to map $/ProjectB as well, though it is not required.

    For example, if you have $/ProjectA/Folder1 mapped to c:\projects\projectA\Folder1, you could map $/ProjectA to c:\projects\projectA.  Then you would be allowed to rename $/ProjectA/Folder1 to $/ProjectB/Folder1.

    After you have renamed the folder, you can change the mappings back to their original settings, if you like.

  • Buck Hodges

    TFS Version Control post summary


    Now that the RC is out, I thought I'd post a summary with links to version control posts from the last several months that I think are relevant.

    Clark Sell posted a VSTS JumpStart with useful links as well.

    Here are some posts from James Manning you may find useful.

    For those of you out there who want to add your own "power toy" to enhance the TFS version control experience in VS, check out How to Write a Team Foundation Version Control Add-in for Visual Studio by Ed Hintz, which also includes adding TFS assemblies to VS.  You could add features like baseless merges, merge history, listing the pending changes in all workspaces or a particular workspace, and deleting other users workspaces (if you have permission).  You could add a check out command that gets the latest version of a file before checking it out.  Or maybe you'll come up with something more interesting.

    There are more links that I should include, but that's enough for now.

  • Buck Hodges

    Using Team Foundation in Eclipse with the TeamPrise plug-in


    I'm still catching up on what's been going on, and I found this on Grace Francisco's blog.  I've highlighted the end of the summary where it mentions using TeamPrise on Linux.

    MSDN Webcast: Accessing Visual Studio 2005 Team System Using the Teamprise Plug-In for Eclipse (Level 200)

    Find out how you can use the Teamprise Plug-in for Eclipse to access the source control features of Microsoft Visual Studio 2005 Team System from within the Eclipse integrated development environment (IDE). In this webcast, we show you how to add new Eclipse projects to a Microsoft Visual Studio 2005 Team Foundation server, import existing projects from Team Foundation Server into Eclipse, and keep projects synchronized. We also look at the Teamprise Explorer client on a Linux virtual machine.


  • Buck Hodges

    How to upgrade to Team Foundation RC


    The Team Foundation RC should be available for download sometime today, and Jeff Beehler provided a high-level description of what's changed.  His first point is the most significant.  There are many, many bug fixes in the RC compared to beta 3.  For version control, merge has improved the most.  It's quite a bit faster and more robust.

    Rob Caron has posted information on upgrading from beta3 refresh to the RC, including the Team Foundation RC Installation Guide.  Those with beta 3 installed will need to upgrade their servers to beta 3 refresh to then upgrade to the RC.  Clients just need the new RC client installed, regardless of the beta 3 variant currently installed.

  • Buck Hodges

    VSTS Load Test team bloggers: Ed Glas, Bill Barnett, Josh Christie


    One of the many great parts of Visual Studio Team System is Load Testing.  As one of the three original projects here in the Durham, North Carolina office, it was known as Ocracoke originally (Version Control was Hatteras, and Work Item Tracking was Currituck -- all three are islands in the North Carolina Outer Banks).

    The Load Testing team continues to ramp up on blogging.  In addition to Josh Christie, Ed Glas, group manager, and Bill Barnett, developer, have started blogging.  Other team members that don't have their own blogs will also be contributing posts.  It's a great way to learn about Load Testing.  Check it out!

  • Buck Hodges

    Baseless merges now record history


    Back in June, I wrote a post on using baseless merges to establish a merge relationship between two items where neither was branched from the other.  A week after I posted it, I had to go back and change it to say that baseless wouldn't record merge history for v1, and thus you would only be able to merge items where one was a branch of the other.

    I'm happy to say that's been fixed both for the RC (available tomorrow) and RTM (available in March)!

    So, if you have two folders, projectX and skunkWorksX, where neither is a branch of the other, you can establish a merge history between the two by running "tf merge /baseless projectX skunkWorksX /r" (or you can re-order the source and target, according to the direction in which you want to initially move changes).  When you are done resolving the conflicts and check it in, you will be able to merge normally between the two with "tf merge projectX skunkWorksX /r" or "tf merge skunkWorksX /r" depending upon which direction you need to propagate changes.

    In v1 you have to use the command line to perform baseless merges.  Also, items that did not originally have a branch relationship will not show up in the Source Control Explorer in VS as able to be merged (you'll have to use the command line).  Those are pretty minor tradeoffs for a really useful feature, though.

Page 1 of 1 (16 items)