Matt Mitrik

Source Control Explorer Extension

2011-10-05T13:34:12Z

I came across a very cool extension for Source Control Explorer today, and thought it was worth sharing more broadly. The TFSSCExplorerExtension is hosted on Visual Studio Gallery, and it adds a number of very useful features:

Move to Folder – Allows multiple items to be moved at once in SCE
Branch to Folder – Allows multiple items to be branched at once in SCE
Drag & Drop – Adds drag and drop support for Move, Branch, and Copy operations
Show/hide deleted items – Quick way to toggle the “show deleted items” option
Destroy – Enables the Destroy command inside of VS

There are a few other cool features as well, but the ones listed above are some that I’ve heard people ask for in the past. Check it out here: http://visualstudiogallery.msdn.microsoft.com/c6642e7f-1a58-4ff0-aef9-0322dcc2b28d

Professional Team Foundation Server 2010

2011-05-11T12:43:48Z

This week I received my copy of one of the latest books on TFS: Professional Team Foundation Server 2010. This book is a great reference for anyone that is working with TFS and is looking for more deep knowledge on setup, administration, advanced branching and merging, migration, build automation, work item tracking, and more. Authors Ed Blankenship, Martin Woodward, Grant Holliday, and Brian Keller all really know their stuff and did a great job of assembling their knowledge and experience in working with TFS together in a great book.

TFS Guide for SVN users

2011-01-19T15:30:51Z

Ed Hintz just posted a great guide for former SVN users that are moving to TFS. He covers a bit of the conceptual differences, and produced a table mapping the most common SVN commands to their equivalent TFS commands.

Check it out here: http://blogs.msdn.com/b/edhintz/archive/2011/01/18/tfs-guide-for-subversion-users.aspx

Customizing Check-in Actions in your Process Template

2010-12-20T22:34:47Z

In my last post, I told users about a client side hack that we added to change the default check-in action from “Resolve” to “Associate”. Most of the time I’ve heard questions about this, it is because a team has customized their process template to no longer include the Resolve state or adopted a template that doesn’t have the concept of Resolve – our own SCRUM template comes to mind…

Last week, Aaron Bjork posted a much better solution for teams with custom process templates. Check it out if you need a solution for changing work item state when checking in changes but aren’t using the Resolve state.

http://blogs.msdn.com/b/aaronbjork/archive/2010/12/17/marking-tasks-and-bugs-as-done-during-a-check-in.aspx

How To: Make “Associate” the default action for work items

2010-12-03T21:39:29Z

I’ve heard this one a lot lately from many people, so I felt it was time to share more broadly. While there is no way to do this in the UI in TFS 2010, there is a registry key that we added late in our release cycle to allow users to configure the default work item association.

To make “Associate” the default action (instead of “Resolve”), set the registry key “HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Behavior\ResolveAsDefaultCheckinAction” to “False”.

FWIW, in our next release, we’re fixing this experience so that you won’t need to hack the registry to change the behavior.

TFS Integration Tools Released on Visual Studio Gallery

2010-08-09T13:49:00Z

Over the weekend, our team released the first fully supported version of the Team Foundation Server Integration Tools. This suite of tools has been developed by the TFS product group with help from the Visual Studio ALM Rangers to provide a comprehensive package to help teams that are migrating from 3rd party ALM tools to TFS. Included in the release are adapters for TFS (2008 and 2010), Rational ClearCase, Rational ClearQuest, a file system based version control adapter, a readiness package including documentation, guidance, and case studies, GUI tools for configuring and running migrations, and sync monitoring tools and reports.

You can download the tools here: http://visualstudiogallery.msdn.microsoft.com/en-us/5a8d1703-7987-4081-ba2f-9d0b68b0ed3e

Any questions or feedback on the tools can be given through the TFS Integration forum on MSDN.

5/11 - It seems that the last update of the TFS Integration Tools broke my link above. The Migration and Integration Solutions page should always contain a working link for the TFS Integration Tools moving forward.

Tips when creating a workspace

2010-07-20T19:31:45Z

I’ve been working with our content team to help publish some guidance on MSDN around using workspaces. To date, it has been one of the biggest points of confusion for users that are new to TFS, so we made a point to create new topics with those points of confusion in mind. While we’re still working on the final guidance to be published, I wanted to post a few pieces of guidance I give to people when they’re setting up their workspace.

When creating mappings for your workspace, keep the following points in mind:

Map high enough (that is, closest to the root, $/) to ensure that you’re not updating your mappings every time a new piece of code is added.
Map low enough to prevent downloading things you don’t need to do your development work or to build your code.
Keep your mappings simple – the fewer the better. Only add complexity if it is necessary.

Balancing each of these things is something that is really only possible when the details of the specific projects are known. There are some general best practices that may also be useful when creating a workspace:

Mapping at the Team Project level is a common approach, and may be a good idea if you only work in one Team Project. Team Projects and workspaces are both tools to provide isolation, so a 1:1 mapping makes sense.
One branch per workspace is a good practice to isolate changes that don’t logically go together. For example, you probably don’t want to see pending changes from your production branch shown along side your changes for your development branch.
Using multiple workspaces is a great way to work effectively if you work on multiple projects in parallel and task switch often.

Hopefully that will provide some help to users that are new to TFS until we have better guidance on MSDN.

How do I find the history for a renamed folder in TFS 2010?

2010-07-02T16:22:26Z

I came across this question while responding to some customer suggestions, so I thought I should make the answer easy to find should others be wondering the same thing…

In the UI, history of folders is recursive - always. This is because most of the time, users care about the history of the contents of the folder. Files on the other hand don’t have the concept of recursive history - you always see the history for the file itself. Now, from the command line, there is an option to show recursive history (/r) and if you run “tf history” on a folder without the recursive option, you'll see the changes to the folder itself. This would include changes such as a rename for the folder itself.

As for getting this in the UI in VS - we've heard multiple requests for this, and we're tracking it as a possible feature for the next release.

Version Control 2010 Upgrade Hotfix Published

2010-06-17T14:54:08Z

Recently, I blogged about an issue in the TFS 2010 upgrade that affected the contents of labels and merge relationships. If you have not yet upgraded to TFS 2010, the hotfix is now available and is highly recommended to be applied before configuring your team project collections. The hotfix has been published on MSDN Code Gallery – find it here: http://code.msdn.microsoft.com/KB2135068

Because this hotfix applies to the upgrade of version control content, it must be applied after TFS 2010 setup is complete, but before configuration is started. At the end of the setup experience, the Success screen is shown (see below), indicating the completion of the installation. Normally, users would continue on to the configuration experience, but in this case, the process needs to be cancelled by un-checking the “Launch Team Foundation Server Configuration Tool” box, which will enable the Cancel button.

After exiting setup, the hotfix executable can be run to update the upgrade steps. Once the hotfix is installed, the TFS Configuration Wizard will need to be re-launched from the Start Menu to complete the upgrade process. As a reference, I’ve shown the welcome screen for the Configuration Wizard. If you get to this screen and haven’t applied the hotfix yet, cancel out of the wizard and apply the hotfix.

Version Control Upgrade KB Article Published

2010-06-04T20:59:37Z

Today we published a KB article for a recently discovered issue when upgrading from TFS 2005/2008 to TFS 2010. This issue exhibits symptoms in both merge and labels – from the KB:

Labels that were created before the upgrade are entirely empty. Labels could be also have incorrect contents.
The merge wizard in Visual Studio does not display all valid merge targets for a given source path/branch.
During merging, merge candidates are shown for changes that were already merged prior to the upgrade.

If you’ve experienced any of these symptoms following an upgrade to TFS 2010, please check out the KB article: http://support.microsoft.com/kb/2193796

We’re also in the process of releasing a hotfix for the issue for any customers that have not yet upgraded to 2010 that will fix the issue. When the hotfix is available, the KB will be updated, and I’ll post back here as well.

Update, 6/17 – The hotfix is now available on Code Gallery: http://code.msdn.microsoft.com/KB2135068

TFS 2010 File Corruption KB Article Published

2010-05-26T14:09:00Z

Recently, we published a KB article that is related to files being downloaded from version control with the incorrect contents. The symptoms from the article:

After restoring a Team Project Collection (TPC) from a backup, files downloaded from Team Foundation Server through version control operations may have incorrect contents.

An example of this is that you perform a Get operation, which downloads a file named Foo.cs, but the contents of Foo.cs are actually from the file Bar.cs. This mismatched content is NOT the result of corruption in the database – it is an issue with stale cache contents. From the article:

In the event of a TPC restore, it is possible that files added since the last backup was taken will be cached on the AT with a FileID that was assigned between the time backup was taken and the restore was applied. If the version control cache was not purged prior to the TPC restore, FileIDs that were reassigned to new files may result in false positive cache-hits, leading to the download of incorrect file contents.

We found this issue very late in the 2010 cycle, and we plan to revisit this in the first service pack. If you believe you have hit this issue, visit the KB article for details on how to correct the problem. Also, if you’re seeing file corruption that is not related to this, please let me know as this would be an issue we would want to investigate and fix ASAP.

KB Article 2025763: http://support.microsoft.com/default.aspx?scid=kb;en-US;2025763

TFS 2010 backwards compatibility known issue: Possible null reference when setting source control permissions

2010-03-12T17:45:09Z

We recently found an issue in the Team Explorer 2010 client while performing backwards compatibility testing, and unfortunately, this wasn’t a bug that we were able to fix for RTM. This issue will be documented in the RTM ReadMe, but I wanted to make people aware of this should they go searching the web.

This issue only occurs when using a Team Explorer 2010 client to modify permissions on Team Foundation Server 2008. Upon checking the "Inherit security settings" check box on the "Security" tab of the "Properties" dialog for an item in source control, some users may hit a condition that results in a null reference exception. This null reference is the result of a pre-existing condition with out of sync identities that some TFS 2008 instances may exhibit. Due to the changes in how identities are managed in TFS 2010, this issue will not occur for 2010 servers.

If this null reference is hit while modifying the inheritance settings, the state of permissions displayed in the "Security" tab may be inaccurate – that is, what is displayed by the individual permissions checkboxes may not be the actual state of that permission. Clicking the "OK" to save the permissions changes may then result in permissions being set that differ from what the user expected (re-opening the dialog will show the correct permissions after they are saved). Clicking "Cancel" on the dialog will result in no changes being applied to the permissions.

While it may be possible to work around this with the 2010 client, or by using the 2010 command line, it is recommended that users trying to modify source control permissions for TFS 2008 use a 2008 client.

Branching by Label in TFS 2010

2010-02-18T17:02:00Z

Several people have noticed that in TFS 2010 the option to branch by label in the UI is no longer present, so I wanted to put up a short post on the subject until we have a chance to fix this (which will hopefully be very near RTM). This change was the result of multiple changes in 2010 around branching:

Server side branching. The introduction of server side branching has a lot of benefits in the usability and the performance of creating new branches. One limitation is that branches defined by workspace specs or labels (which can be defined by workspace specs), can’t be created without a workspace. Hence, the server side branching option only allows branches with the version specs presented in the branching dialog.
Making server side branching the default in the UI. Because of the great performance improvement of creating branches entirely on the server, we wanted to ensure that users would benefit from the platform change any time a new branch is created.
First class branches. With the introduction of first class branches, we added a new branching dialog for creating new branches. It is this new dialog where we default to server side branching. Branching folders is still the same experience that existed in 2008 that allows branching by labels and by workspaces.

The result of these changes was that the UI now only presents users the option to create new branches based on Changesets, dates, or the latest version of the parent branch. Until we have a chance to resurface the option to branch by labels in the UI, the command line can be used as a workaround to create branches by label (even when branching first class branches). When we have made the UI changes to add back this option, I’ll post back here.

For more info on branching on the command line, see the Branch Command topic on MSDN.

For more info on changes to branching in TFS 2010, see the post on First Class Branches.

UPDATE: This issue has been fixed as a part of the QFE Rollup and the fix will be available in SP1. You can download the QFE here: http://support.microsoft.com/kb/983504

Upgrade vs. Migration: TFS Integration Platform

2010-02-08T14:34:00Z

This is the seventh blog post in a series about Upgrade and Migration for TFS.

In some migration scenarios, neither upgrading servers nor losing history are viable options:

“I have Team Projects I need to migrate from one existing TFS 2008 server to another TFS 2008 server, and I need to keep the history”

In scenarios such as this one, using the TFS Integration Platform to preserve some history may be an option. This platform was designed to facilitate the development of migration tools that connect other systems to TFS, and all of the logic to interface with TFS and move data between systems is provided with the platform.

Using the TFS Integration Platform to move data does allow historical versions of version control and work item tracking data to be preserved, but it has some of the same disadvantages of the Tip Migration approach: loss of date-time information, and changeset and work item IDs are not preserved. Furthermore, migrations involving the TFS Integration Platform also suffer from the problem of time compression, that is, actions that occurred over a long period of time in the source system are replayed in a short amount of time in the destination. The result of this time compression is that many of the reporting metrics of the destination TFS server are inaccurate.

The cost of using the TFS Integration Platform to migrate Team Projects is not trivial, and should be carefully weighed against the benefit of preserving some of the historical revisions. Typically, this option should be reserved only when the other options previously discussed have been exhausted. For more information, please visit the TFS Integration Platform CodePlex project page.

Upgrade vs. Migration: Tip Migration

2010-02-04T15:07:00Z

This is the sixth blog post in a series about Upgrade and Migration for TFS.

Thus far, all of the recommended approaches for scenarios involving migrations of data between TFS 2010 servers have started with upgrade. For some customers, upgrade may not be an option (in the cases where it is an option, it is strongly recommended):

“I have Team Projects that I need to migrate from my existing TFS 2008 server to another TFS server, but I don’t want to upgrade”

Client Compatibility

It is important to understand that upgrading a TFS server does not mean that users are required to upgrade their Visual Studio clients to continue using TFS. Along with the TFS 2010 release two client compatibility GDRs have been released to ensure that TFS 2005 and 2008 clients are compatible with TFS 2010 servers. For more information on the compatibility releases, please see the blog post that details the Compatibility Matrix for TFS 2010 and Team Explorer 2008 and 2005.

Tip Migration

If upgrading to TFS 2010 is not an option, the recommendation for moving Team Projects is to copy the latest versions to the destination server, leaving the history behind on the original server. Copying the tip versions is a relatively low cost migration option, and involves fairly simple procedures for version control and work item tracking data. The major disadvantages of this approach are the loss of historical changes, date-time information, and changeset and work item IDs.

For version control, a workspace that maps all files for a Team Project can be used to get the latest copy of all files and folders to a client machine. Those files can then be added to the new Team Project on the destination server. For details on using version control, see the MSDN documentation to Create a Workspace and Get Files and for Placing Files under Version Control.

To move work item tracking data, Excel can be used to export the work items that are to be moved to the new Team Project. A query can be created that selects the work items that are desired to be moved to a new server, and those items can be opened in a bound Excel sheet. That Excel sheet can later be bound to a different TFS server and those work items can be added to the destination Team Project. For more information, see the MSDN documentation for Managing Work Items Using Office Excel Bound to Team Foundation Server.

Upgrade vs. Migration: Team Project Move

2010-02-02T21:10:08Z

This is the fifth blog post in a series about Upgrade and Migration for TFS.

A common migration scenario is one involving moving Team Projects between servers:

“I have a Team Project on one TFS server that I need to migrate to another TFS server”

This can be a challenging task, especially when migrating to TFS 2005 or TFS 2008, as Team Projects are not fully encapsulated. As with the consolidation scenario, the best approach is to leverage the features of Team Project Collections in TFS 2010. For this reason, the recommended first step is to upgrade any server that has Team Projects to be moved to another server.

Although TFS 2010 does not allow Team Projects to be individually moved in the way TPCs can be moved, there is a supported set of actions to split one or more Team Projects out of an existing TPC. The TPC Split process allows a new TPC to be created that maintains full fidelity of the data as it existed in the original TPC. To move one or more Team Projects from one TFS 2010 server to another, follow the MSDN topic to Split a Team Project Collection.

Much like the other TPC features, the TPC Split process has undergone significant testing and is fully supported. Another advantage of using TPCs to move data is that the process operates in an offline manner involving database backups, meaning the servers to not need to be connected or accessible from a single location. This is particularly useful when moving data between domains without a trust relationship.

Upgrade vs. Migration: Server Move

2010-02-01T16:55:24Z

This is the fourth blog post in a series about Upgrade and Migration for TFS.

There are some customers that present migration scenarios that are focused on hardware changes:

“I want to migrate my TFS server to a new set of hardware”

In the case of an upgrade to TFS 2010 being performed in conjunction with a hardware move, the steps to Move a Team Project Collection as described in the consolidation scenario can be used. The difference in this scenario is that the second server that will use the new hardware will not have any TPCs created until the TPC from the old server is moved onto it. Using the TPC move process also has the advantage that it can be done “offline”, which can be useful if both servers will not be active at the same time.

If upgrade is not an objective, or if the move is to be performed on a 2008 or 2005 server, see the MSDN documentation to Move Your Team Foundation Server from One Hardware Configuration to Another. Another useful resource if an upgrade to TFS 2008 is being performed is the blog post on Upgrading to Team Foundation Server 2008 while Changing Servers.

Upgrade vs. Migration: Server Consolidation During Upgrade

2010-01-29T20:28:13Z

This is the third blog post in a series about Upgrade and Migration for TFS.

Sometimes, customers present more complex scenarios that aren’t solved by a simple upgrade:

“I have two TFS 2008 servers that I need to migrate to a single TFS 2010 server”

Often times, upgrade scenarios are paired with other objectives that lead users to think of them as migrations. Consolidation of multiple existing servers into a primary upgraded server is a common scenario involving multiple goals, one of which is upgrade. In a consolidation scenario, the best approach is to leverage the features of Team Project Collections in TFS 2010. TPCs are fully encapsulated entities in TFS 2010, and they can easily be moved between server instances, even when crossing domain boundaries. To learn more about Team Project Collections in TFS 2010, visit the MSDN article on Organizing Your Server with Team Project Collections.

In a consolidation scenario, the best approach is to start by upgrading each of the existing servers to TFS 2010. Starting with upgrade has all of the advantages outlined in the previous scenario, and it allows the TPC features to be used to move data between servers with full fidelity.

To accomplish the task of moving each of the Team Project Collections to a central server, follow the MSDN documentation to Move a Team Project Collection.

Upgrade vs. Migration: Upgrading to a Newer Version of TFS

2010-01-26T16:53:21Z

This is the second blog post in a series about Upgrade and Migration for TFS.

One of the most common statements I hear from customers looking at migration is similar to the following:

“I have a TFS 2005/2008 server and I want to migrate to TFS 2010”

This is not a migration scenario, but rather an upgrade scenario. Any scenario in which the primary objective is to move from one version of TFS to another newer version is an upgrade. In any situation where an upgrade to a newer version is to be performed, the recommended approach is to follow the MSDN documentation for Upgrading Team Foundation Server and to use the Team Foundation Installation Guide (2008 version, 2010 version).

Using the supported upgrade process that is given in the TFS documentation is recommended for multiple reasons. First, it guarantees that all of the data and metadata stored in TFS is properly transformed for use in the new version. The upgrade process is also highly tested in numerous configurations of hardware and software versions. Finally, because the upgrade process is part of the released product, any issues encountered during upgrade are fully supported by customer support.

Additional Resources

MSDN Upgrade Documentation - http://msdn.microsoft.com/en-us/library/ms404851.aspx

TFS 2010 Installation Guide - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2d531219-2c39-4c69-88ef-f5ae6ac18c9f

TFS 2008 Installation Guide - http://www.microsoft.com/downloads/details.aspx?familyid=FF12844F-398C-4FE9-8B0D-9E84181D9923&displaylang=en

Upgrade vs. Migration: Definitions

2010-01-25T20:29:05Z

Being the Migration PM for the TFS team, I get a lot of “migration” questions from users. After a few rounds of questions, most of the time the conclusion is reached that the user wanted something other than migration, say, an upgrade. With the RTM release of TFS 2010 just months away, I thought that it would be great to have a few blog posts out there to help people determine if they really want to migrate to 2010, or if they would be better served by an upgrade or other option.

Over the next few days, I’ll be posting some of the common scenarios that people often present when they talk about wanting to perform a migration. Before getting into the scenarios, I wanted to clarify the definitions of Migration and Upgrade in the context of TFS.

Upgrade

An upgrade refers to the process by which an existing TFS server is moved from one version to a newer version. Upgrades are always fully supported and are tested in many configurations before being released. In an upgrade, data on the server is transformed at the database level, and all data and metadata are preserved.

There are also multiple flavors of upgrades: In-Place and Migration-Based. An in-place upgrade is defined as an upgrade that when complete will use the same set of hardware that is running the current TFS version. A migration-based upgrade is defined as an upgrade involving a second, duplicate set of hardware which will host the new version of TFS when the process is complete. Note that despite having a similar name, a migration-based upgrade is NOT a Migration (see definition below).

For more information about the differences between in-place and migration-based upgrades, please Bryan Krieger’s blog post on Team Foundation Server 2010 Upgrade.

Migration

A migration refers to the process of replaying actions from one system into another system. One of the key differences as compared to an upgrade is that a migration is a lower fidelity data transfer. In TFS, only version control and work item tracking data can be migrated between servers – build data, reports, and numerous other pieces of metadata are not able to be migrated. In general, available migration tools have significantly less testing than the upgrade process, and most available tools have limited support (as they are released out of band).

In the case of a migration, the data transformations are done using only the public APIs, which are limited in providing only certain pieces of information while moving data. The result of these limitations is that some data is lost or distorted in the process of migration. Examples of this are artifact IDs (changeset numbers, work item IDs), date-time stamps, area paths, and iteration paths.

Server Move

Another term included here is server move, which is used to describe the process changing the hardware associated with a server. During a server move, the version of TFS is not changed. While a server move is neither an upgrade nor a migration, they are often performed before or after an upgrade, and are often confused with migration.

Scenarios

Stay tuned for additional posts on common scenarios!

Dogfooding the TFS Integration Platform

2009-12-18T17:45:47Z

Late last night, we published updates to the TFS Integration Platform on CodePlex. In addition to these changes containing new features, numerous bug fixes, and documentation refreshes, the updates marked the beginning of the dogfooding effort to sync our internal server to the TFS server used for the CodePlex project. We’ve already been dogfooding the platform internally to sync two production TFS servers, and this is now another example of our commitment to dogfooding.

To get the latest source code or to see the contents of the updates, check out the Source Code section of the project. You’ll also notice additions in the changeset comments (see below) that are added by the tool as it migrates the changesets from our release branch to the CodePlex project. It’s really nice to be able to automate our updates to CodePlex and dogfood our tools at the same time!

If you have any questions or feedback on the TFS Integration Platform, be sure to visit our forum and let us know.

New Forum on MSDN

2009-11-17T16:40:54Z

For a long time, we have had no home for questions related to migration offerings such as the VSS Converter, as well as general questions about our tools, partners, and service offerings. We’ve recently added a new forum on MSDN to serve as the home for questions related to all of these things: Team Foundation Server - Migration and Integration

With the recent release of the TFS Integration Platform, we’re also leveraging this forum as the discussion forum for the platform and the CodePlex project. This will help to drive all of the questions and discussions for the entire TFS migration space to a single location.

Something this forum is not intended to support are questions related to upgrading between TFS versions. For those questions, the TFS General (http://social.msdn.microsoft.com/Forums/en-US/tfsgeneral/threads) or TFS Setup (http://social.msdn.microsoft.com/Forums/en-US/tfssetup/threads) forums are your best bets.

TFS Integration Platform Alpha Released on CodePlex

2009-11-11T20:39:48Z

Today, we released the Alpha version of the TFS Integration Platform on CodePlex. For all of the details, including the docs and source code, check out the project page: http://tfsintegration.codeplex.com

If you check out the project page, you’ll soon realize that this project has replaced the former TFS Migration and Synchronization Toolkit that was hosted on CodePlex. We’ve actually reused the same project page, but have updated the URL and project information to reflect the changes that have been made. Visiting the previous project URL (http://migrationsynctoolkit.codeplex.com) will redirect to the current project page.

The TFS Integration Platform is different from its predecessor project in many ways. First, we listened to the feedback that the community had on the old project and used that to shape the new project. Here are a few things we’ve changed this time around:

Improved quality and robustness. This is a major area of improvement for this project, and one big change for us is that we’re actually dogfooding this platform in production. We had a need to synchronize two servers internally (see Brian Harry’s blog post on the subject), and we’ve used this platform to build that synchronization tool. The net result is that quality and robustness are a top priority for our team, as we have hundreds of people relying on our tools each day.
Increased transparency to the community. In the past, we just dropped a few releases on the community, and didn’t follow up with the needs of the community. This time around, we’re starting with an alpha release, which was built with insight from MVPs, and we plan to have very frequent updates of the code base on CodePlex (ideally multiple times per week). The goal here is to shrink the feedback loop so that we can end up with the right platform.
Better documentation. Along with the improvements to the code, we’ve worked hard with the VSTS Rangers to create detailed docs to help developers make sense of the platform. Willy from the ranger’s team has been blogging about this effort for some time, so check out his blog post that summarizes everything that they’ve done to date.
Better serviceability. In the past, we had nothing that resembled a binary release, let alone one that was serviceable. This time around, we’re making an MSI available to install the platform binaries to make servicing of tools built on the platform much easier.

Another change that we’ve consciously made was to rebrand the project to the TFS Integration Platform. We felt that the description “toolkit” wasn’t accurate compared to what other “toolkits” consisted of, and that our functionality was more in line with what a “platform” offers. Changing from “migration and synchronization” to simply “integration” was about simplifying the message about the purpose, and helping to disambiguate from upgrade scenarios which are often confused with migration. Overall, we hope this name change results in a clearer focus for this project.

So, if you’ve looked at the Migration Toolkit in the past, or have a need to integrate another system with TFS, check out the CodePlex homepage for the project and stay tuned for more updates!

New Branch and Merge Permissions

2009-11-10T20:56:30Z

In a previous blog post about the new First Class Branches that we have added in TFS 2010, I mentioned the addition of two new permissions related to branching and merging. In this post, I want to go into a bit more detail about these permissions, explaining what each enables, the motivation for adding each permission, and how users upgrading from TFS 2008 are impacted.

Manage Branch

The first of these new permissions is the Manage Branch permission. Users that have this permission set to Allow for a given path can do the following:

Convert folders to branches (and branches back to folders)
Update metadata for a branch (i.e. owner, description)
Create additional child branches from the original branch
Change the relationships between branches with merge relationships (i.e. reparenting branches)

One very interesting point about this permission is that it is only relevant for folders that have been converted to Branches – it does not prevent users from branching ordinary folders for which this permission has been denied.

The primary motivation for adding this permission was to enable which users could create new branches. In many organizations, there is a desire to establish a branching structure, and then have developers work in the branches the team has agreed they need. Because the permission is path scoped, and branches can still be organized in folders, this still enables teams to group branches such that some branches can be further branched by users but other cannot.

An example scenario around this permission would be to deny Contributors the ability to Manage Branch under $/TeamProj/Main and $/TeamProj/Releases, but grant the permission under $/TeamProj/FeatureBranches. That way, users could create sub branches for their feature branches, but couldn’t branch off of release branches or Main.

Merge

The Merge permission is the second new permission we have added for version control. Users that have this permission set to Allow for a given path can do the following:

Pend merge operations on branches, folders, and files under the specified path

Note that this Merge permission is only for the target path of a merge operation. There is no permission to prevent a particular branch or folder from being merged to another path. Unlike the Manage Branch permission, the Merge permission is not tied to branches – it has the same behavior for folders and branches under a given path.

The motivation for adding the Merge permission was similar to that of the Manage Branch permission. In some teams, there is a desire to have certain developers handle the task of merging code between branches, while other developers will always work on one branch or another.

Upgrading from 2008

Adding new permissions to the 2010 release presented the problem of how to assign these permissions on upgrade. When we added these new permissions, we had one clear goal for the upgrade:

After upgrading, users should be able to continue using all features they had permissions to prior to the upgrade.

Following this guideline, users upgrading to 2010 will be granted the new permissions as follows:

For a given path, users that are granted the Pend Change (aka Edit) permission will be granted both the Manage Branch and Merge permission. Likewise, users that have been denied the Pend Change permission will be denied the new permissions.

This effectively means that users that were granted Pend Change permission before upgrade would be able to branch and merge, and after upgrade they will still have the permissions to branch and merge.

It is also important to note that during upgrade, folders with branch relationships to other folders are automatically converted to branches. Due to an oversight, this created a problem during Beta 2…

Bug in TFS2010 Beta 2 Upgrade

Originally, we had planned to grant the Merge permission to users with the Pend Change permission, and Manage Branch would be granted to users with Admin Project Rights. The thought here was that converting to branches and creating new branches was targeted more towards project leads than developers, and because the functionality was new, that users branching and merging folders wouldn’t be impacted.

Some time later, we decided we needed to automatically detect and convert folders to branches during the upgrade process. When we implemented this and performed our upgrade testing, we didn’t realize that after upgrade users without Admin Project Rights couldn’t create new branches.

The net result here is that for teams that have upgraded from 2008 to Beta 2, only users with Admin Project Rights will be granted the Manage Branch permission. We have since fixed this bug so that users upgrading from 2008 to RC or RTM will have the permissions applied as described above. Note that users upgrading from Beta 2 to RC/RTM will not have their permissions changed (we don’t want to overwrite any customizations that may have been made since upgrading to Beta 2).

Using VSS Converter in TFS 2010 Beta 2

2009-10-29T13:43:30Z

TFS 2010 Beta 2 has been out for a few days now, and I’ve heard of quite a few users hitting errors when trying to migrate their VSS databases to TFS using VSS Converter. If you’ve hit the error message below, keep reading for a workaround that enables you to use VSS Converter from TFS 2010 Beta 2.

Symptom

TF60070: Unable to connect to the Team Foundation Server: 'http://TFSServer:8080/'. Please ensure that the Team Foundation Server exists and try again.

Workaround

With the addition of Team Project Collections in TFS 2010, the VSS Converter utility needed to have its connection string format updated to enable it to connect to TFS. During Beta 2 development, we updated the tool so that it would accept the collection name as an input parameter. The unfortunate part about this change is that we were not able to update the documentation for the sample migration setting file in time for Beta 2. For the RTM release, we’ll be sure to have the walkthrough and other docs updated to include this new setting.

To workaround the issue, you’ll need to add a new attribute to the <TeamFoundationServer> node in the settings file. Here is an example of what the setting would look like if you were migrating to the default collection:

<TeamFoundationServer name="myserver" port="8080" protocol="http" collection="tfs/DefaultCollection"></TeamFoundationServer>

If during the configuration of TFS, you specified a different path than "tfs" you need to prefix the collection name with that path component. Likewise, if you're not using the DefaultCollection, or want to migrate to a named collection, insert that part of the name after the "/". If you are not using any path component (i.e. an upgrade scenario), then you will want to specify only the collection name, omitting the "/".