FAQ: Visual Studio Team Foundation Server

See the quick start article on MSDN: Installation and Administration of Team Foundation Server.

Here are some pros and cons for each approach:

See Buck Hodges’ MSDN forum post: Backup and restore procedures for TFS.

The Developer Division After-market Community Solutions team has released the first beta of the TFS Administration Tool.

“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.”

See Buck Hodges’ blog post: Determining the amount of space required to store files and work items.

Yes. Multiple files checked-in at the same time are atomically committed to a SQL Server 2005 database and a referencable artifact known as a ChangeSet is published. This can be used at a later point in time to view the contents of a check-in, associate to a work item or build. It can also be used the same way a label would be used “Get me all the source code as of ChangeSet 155” which would include the image of the entire source branch (not just the changed files) as of that moment.

Yes. You can use the Visual Studio Team Foundation Server MSSCCI Provider Beta 2, but be sure to disable strong name validation.

See Vertigo Software’s blog post: TFS Source Control using the Console.

No. We receive many requests for this, but our contention is that the person defining the policy can’t envision the situations that will occur where policy must be overridden. Therefore, we designed it to be fully auditable by including policy compliance data in the changeset details and in the check-in mail that is delivered, but left it up to the developer to determine whether they have a good reason for overriding.

TFS uses the reverse delta model as most source control systems do. However, there are several notable things that TFS does. First creating the reverse deltas is performed asynchronously as a background task. At first, the new copy is uploaded and saved. Sometime later (usually not very long), a background job will run and convert the older version from a full copy to a reverse delta (assuming the delta is actually smaller than the original – usually, but not always the case).

Because re-creation of old versions can be time-consuming (especially if you have to apply many reverse deltas), TFS stores the copies of the most recently used files in a cache on the application tier (AT) computer. This eliminates the performance difference between accessing the most recent version and accessing older versions.

Note: The reverse delta mechanism works for text and binary.

Shadow Folders are a specific concept supported by Visual SourceSafe. Shadow Folders are typically used as part of a build process. There is no direct equivalent in Team Foundation Server. To imitate this functionality you can create a separate workspace and have a scheduled task to sync, “Get Latest” on a regular basis. If you are using Shadow Folders as part of a build process however, you may want to look at doing this as part of a build task using Team Build.

The underlying repository, SQL Server 2005, does support remote sites and two-way replication; this is not a tested or supported scenario for Team Foundation Server usage. Remote development shops are supported through a remote proxy server that caches file downloads (which is a high bandwidth activity). The intention of the Team Foundation Server Proxy is to boost performance by caching copies of source code files in a remote location. Remote users will still access the central server for exchange of SOAP messages and check-ins/uploads through HTTP, traversing firewalls. All downloads (i.e. Get Latest) will be cached through the remote proxy. See Managing Remote Connections to Team Foundation Server Proxy.

Unlike many past source control plug-ins for Visual Studio, when you rename, move, or delete a source-controlled item, you do not have to worry that your change will not be properly shared with your teammates. The change is isolated in your local workspace as a pending change until you check it in. When you do so, the change is propagated to other users’ workspaces the next time they perform a Get or Check In operation. From the command line you can specifically use the rename or its move alias to rename/move a file or an entire folder. This is automatically done inside the IDE in relation to a rename/move of a file.

There is really only one source code control event, and that is the one that is raised on check-in. Subscription is through the general event model that is discussed in the extensibility kit.

A file or folder deleted in the source branch will be deleted in the target branch as part of the merge. In this scenario, the items that were deleted in the Development branch will be deleted in the Test branch.

Deletions are fully recoverable with the “undelete” operation. You wouldn’t want to do a SQL restore because that would roll back every change to the TFS in the time since the file was deleted.

No.

An administrator can specify exclusive check-out on team projects or file types. If either is set for exclusive check-out, exclusive check-out will apply. For this question, the answer is “no” but if they have a general class of files (that is images) with known extensions (.bmp, .gif, .jpg), they can configure them for exclusive check-out.

The main scenario here is deleting a file (by mistake or intentionally) outside Team Foundation, and then trying the retrieve that file back from source control. If the file version has not changed, the server thinks the user already has the file and does not copy it over. This is because the server keeps a list of files that the user already has and when activities are made outside source control, this list becomes out-of-date. Team Foundation source control does have a force Get option which will provide the functionality that you must have to obtain the desired version but it is currently partially hidden under the Get Specific Version Dialog box as a check box selection item.

Clicking View, clicking Other Windows, and then clicking Source Control Explorer will display the Source Control Explorer window in the IDE.

No.

You can do this either by clicking the Add icon or by clicking File, clicking Source Control, and clicking Add To Source Control.

Team Foundation source control lets you limit check-ins by setting up check-in policies that are evaluated before a check-in can take effect. The easiest way to do this is by authoring a policy that checks if the user is trying to check-in a binary file from a given folder structure and reject or accept it in accordance with the policy.

Yes, for the source files under that team project top-level folder.

If a file is under source control, it means that is read-only and the only way to save an edit is to check out or change the file properties back to read/write. If editing the file is all that you want to do, click Tools, click Options, click Source Control, and then click Environment to obtain an option where you can change the settings not to check out files automatically on edit.

The mapping of the source control server to a local folder is performed at a workspace level. Because the way to remap a root directory of a team project is to change the workspace, you can change the workspace by clicking File, clicking Source Control, clicking Workspaces, and then clicking Edit. As soon as you are there, change the Local folder location that is mapped to the source control folder.

Team Foundation source control does not support the promotion model using sharing and pinning. Instead, we use branching and merging as the features that drive our promotion modeling. For a more detailed visual explanation, see the TechEd 2005 presentation made by Doug Neumann.

No. The same functionality can be achieved by either using labels or branches in Team Foundation source control.

Traditional 3-way merges work in the the following manner:

• Identify a base version (automatically by taking advantage of merge history)
• Compute an update that if applied to the base will provide the derived file1 (left)
• Compute an update that if applied to the base will provide the derived file2 (right)
• Merge both updates into the base version and create an output which is a merge that has both changes from file1 (left) and file2 (right)

A baseless merge scenario is created when the application cannot identify a base version and requires that the user to define one. Team Foundation relies on merge history to identify a base version but when branches do not have a direct relationship (meaning they are not branched from one another or in other terms are not parent-child) this history does not exist. At this point the application cannot establish a base version and a baseless merge is the only way to merge changes. Baseless merge in Team Foundation Version Control works the following way:

• User provides a range of changesets from the source branch they want to merge this is then considered both the base and file1 (left)
• User provides the target branch where file2 (right) is located
• The application computes an update so when applied to the specified base creates an output file that contains all the changes from file1 (left) and file2 (right)

One note to highlight is that when you use baseless merge, no relationship between these files or branches is kept.

Team Foundation is being built as the future source control tool for Microsoft and therefore is advanced enough to support the source control needs of a very large software development organization. It supports parallel development through branching and merging and has a special focus on making these operations easy and flexible. As for what it does not support, pinning and sharing are two examples. We performed a detailed analysis of these features and found that in every identified scenario, there were other configuration management practices that better accomplished the user’s goals.

You can use another source control or work item tracking systems instead of Team Foundation’s corresponding features. Sometimes, you may find that the integration between a third-party tool and the other Team Foundation features is not as rich as with the full Team Foundation environment. We are encouraging other tool vendors to take advantage of the integration and extensibility features of Team Foundation to bridge this gap.

The Team Foundation-Visual SourceSafe converter tool transfers files, folders, version history, and user information from a Visual SourceSafe database to Team Foundation source control. Read more.

Although there is no converter available from Microsoft that will migrate source code from CVS or Subversion, ComponentSoftware (not affiliated with Microsoft) is offering CS-Converter for evaluation. From their press release:

“CS-Converter is a powerful and reliable conversion tool, used to migrate from various legacy version source control systems (such as RCS, CVS, Subversion and Visual SourceSafe) to Microsoft Team Foundation Version Control (TFVC) system.”

See Nagaraju Palla’s blog entry: Building binaries targeting .NET 1.1 and .NET 1.0 in TeamBuild.

Alternatively, you can try MSBee, an addition to MSBuild that lets developers build managed applications in Visual Studio 2005 that target .NET 1.1 as is supported on the Developer Aftermarket Solutions and Powertoys forum.

Yes. See Gautam Goenka's blog post: Using AssemblyInfo task with Team Build.

Yes. See the MSDN article Continuous Integration using Team Foundation Build.

See the Team Foundation's WebLog post: Customizing Work Item Types.

See the Team Foundation's WebLog post: Customizing Process Templates. Also, check out the Process Template Editor from the VSTS Customization Workspace.

Unfortunately you cannot organize queries into a folder structure in V1. The closest thing that you can do is copy them into your favorites folders and organize them there.

You can send a query by copying it to the clipboard and pasting it into e-mail. The recipient can drag it into the document well and then use Save as to save it either as a public or private query.

Mitch Denny has an informative two-part blog post on this subject. See Yesterday's Weather for Team Foundation Server Part 1 and Part 2.

See the MSDN article: Walkthrough: Migrating ClearQuest Work Items to Team Foundation.

See Rob Caron’s blog post: Project Server – Team Foundation Server Integration.

• Microsoft Solutions Framework (MSF) for Capability Maturity Model Integration (CMMI) Process Improvement
• MSF for Agile Software Development

• Macroscope for Visual Studio 2005 Team System by Fujitsu
• Rational Unified Process (RUP) by Osellus
• SCRUM by Conchango
• Extreme Programming (XP)

See Bryan MacFarlane’s MSDN forum post: Warehouse Troubleshooting Guide.

Many of the tools in Visual Studio 2005 Team System are tools that Microsoft has used internally for years; such as profiling, static analysis, and work item tracking. Microsoft already has plans to use Visual Studio 2005 Team System for product development.

Team Foundation Server can support teams of up to 2000 users. For more information, please see Brian Harry's blog post: TFS Scalability.

We are regularly using (‘dogfooding’ in Microsoft-speak) Team Foundation Server in our own development teams. Please see John Lawrence’s blog post: Latest Team System Dogfood Statistcs for more information about this work.

See Buck Hodges’ blog post: How to improve command line performance.

You can use Visual Studio 2005 to compile your application and specify that it should run on a 64-bit operating system either as a native application or under WOW64; however, Visual Studio 2005 itself (including Team Suite and the role-based editions) is a 32-bit application and when it is installed on a 64-bit Windows operating system will run under WOW64. Also, Team Foundation Build is a 32-bit application and when it is installed on a 64-bit Windows operating system will run under WOW64. For more information, see Visual Studio Development Environment 64–Bit Support and Visual Studio Team System 64-Bit Support.

We do not think about the size of teams as much as the level of integration necessary. Some small teams need process methodology integration, issue tracking, integrated source code control and policy management and they should use Team Foundation. Conversely, if they are only looking for source code control, the forthcoming release of Visual SourceSafe has many improvements that should satisfy their needs.

The Team Foundation source control proxy is designed to boost network performance by caching copies of source control files in a remote location, local to the developer needing the files but away from the main source control location. By storing copies in the remote location, typically connected to the source location through a slower link than your local area network, the proxy helps each individual user avoid a costly download of the files to their workspace across the slower connection.

Yes. In order to do this you will have to buy Visual Studio Team Foundation Server and a Client Access License for appropriate communication with the server. Team Explorer that is included with Team Foundation Server, is a stand-alone client that uses the Visual Studio 2005 shell providing a UI for source control, work item tracking and all the other features.

For more information about licensing Visual Studio Team System (including Team Foundation Server) see the Team System Licensing White Paper.

Purchasing Visual Studio

See the Visual Studio Developer Center’s Customize and Extend Visual Studio page.

Team Foundation Server

• Team Foundation Server Administration Tool
• Team Foundation Server Work Item Utility
• Continous Integration (CI) Sample
• Team Build Samples
• CruiseControl.NET
• Project Server Connector
• Team Foundation PowerToys

Team Foundation Client

• VSTSEclipse
• TortoiseVSTS
• Personify Design Teamlook
• Teamprise Mac/Unix/Eclipse
• TeamPlain Web Access for Team System
• TeamPlain VS2003 Plugin for Team System
• TeamPlain Eclipse Plugin for Team System

Visual Studio 2005 Team System enables partners and customers to extend Team System with their own internal or commercial tools and process frameworks. As the platform on which Team System is built, Team Foundation Core Services enable third-parties to extend Team System and to share reporting, eventing, groups and permissions, linking, administration, and navigation capabilities. Besides the Team Foundation Core Services integration services, each tool in Visual Studio 2005 Team System may be extended through its own APIs or services.

For more information, see the Extensibility Center.