Child pages
  • Team Foundation Server (TFS) Integration
Skip to end of metadata
Go to start of metadata


This document covers implemented features and important issues related to IntelliJ IDEA TFS integration plugin, and is updated on every new feature or plugin improvement.

Currently the development is focused on supporting source control functionality without team projects management, working items, reports, build etc.


Workspace is a key concept of TFS that represents a context where all interaction between client and user occurs. Workspace is identified by its owner (domain\username) and name (unique among all workspaces that belong to an owner), and is configured for a specific server (using its URL) and a client computer (using its network name). Workspace contains a set of mappings (aka working folders) between folder in a client filesystem and a server repository.

The following restrictions apply to workspaces and mapping definitions:

- Workspace cannot contain more than one mapping of the same local or server folder (irrelative to the hierarchy level)
- A single local folder (on any hierarchy level) cannot be mapped in more than one workspace on the same client

Working folders and workspaces are stored on a server. All VCS internal data: base revisions, conflicts etc. is stored (unlike with other VCS) on a server in the context of workspace in use. Therefore, there is no way to determine if a given local folder is under version control or not, other than to query a server for a list of workspaces and mappings. This is why TFS Configuration page in IntelliJ IDEA Project does not include a project-specific part, but workspace and server item can be determined from the list of servers the plugin works with and information they provide, for any local folder or matching server file.


TFS uses NTLM authentication, so native Windows applications (i.e. Microsoft Team Explorer) authenticate silently with system credentials. IntelliJ IDEA users must always specify their username and password because of limitations posed by Java Runtime.

Servers & Workspaces Management

To see or change the list of servers used as workspaces and mappings, as well as access credentials, open the Workspaces Management under Global Settings on the TFS Configuration page. This list is populated from the same cache that is used by Microsoft Team Explorer (%USERPROFILE%\Application Data\Microsoft\Team Foundation folder). All other information, including server credentials is stored with IntelliJ IDEA configuration settings.


Use the TFS Checkout Wizard (Version Control, Checkout from Version Control menu) to check out files or folders from server. If you know the server from which you are checking out the files, all you need is to specify a source path, local path and working folder (mapping). Indeed, server path can be determined from local path and mapping, and vice versa. Required mapping can be found (or created) based on given local and server path.

TFS Checkout Wizard gives you two options: automatic mode (recommended), where you specify server and paths (source and destination), allowing the new workspace with required mappings to be created on checkout. Manual mode (if you are an expecienced user) allows to manually configure workspaces and mappings (in the same way as with Workspaces Management dialog), in which case you need to select a workspace and server path from which a target local path will be inferred. In both cases folders that are checked out are version-contolled from the moment the appropriate mapping exists.

Checkin Policies

Checkin policy is the rule that is executed before every checkin to ensure that a selected changeset is OK to commit. For example, a policy may verify that a valid comment is specified for a changeset, or that required work items are associated with it, or that file names that it includes match corporate naming standatds, etc.

Policies are stored on a server and are executed on a client machine. Client application loads policy definitions (policy ID, name, description, and configuration settings) from the server and searches by the ID for the corresponding implementation classes that are installed locally. Then, the classes are instantiated, initialized with policy configuration and executed. You can create custom policies, install them locally as plugins and then load the new definitions to server.

As for now there are two policy definition formats: binary format by Microsoft and Teamprise XML. Therefore, at a a given moment of time, a single team project may have two independent groups of policies set up: one for use with Team Explorer, and another - with Teamprise. IntelliJ IDEA provides a limited support for Microsoft definitions format: you can provide custom policy implementation by specifying its ID that matches the policy definition configured by Team Explorer. In this case IntelliJ IDEA will evaluate the policy on every checkin. Because of binary format implementation changing policy configuration or managing policy definitions on server is not supported. IntelliJ IDEA is compatible with Teamprise type of policy definitions and provides support for evaluating, changing configuration, and managing policy definitions on server (Check In Policies button in Manage Servers and Workspaces dialog). You can select which type of policies to apply on checkin.

To implement a custom checkin policy, take a look at the example we have provided.

To control whether IDEA should evaluate Team Explorer or Teamprise policies, open File | Settings | Version Control | VCSs | TFS dialog page and use corresponding checkboxes in 'Checkin policies compatibility' group. Since checkin policies evaluation is essentially client-side task (which TFS server does not care of), given developer can easily bypass it and commit the files directly by simply unchecking all the checkboxes. To prevent this, one (that has administrator permissions) can enforce policies evaluation by overriding these settings for a certain project using corresponding checkboxes in Check In Policies dialog.

  • No labels