Walkthrough: Exploring Team Foundation Source Control

Article
09/24/2007

This walkthrough demonstrates source control integration features in Visual Studio 2005.

This walkthrough describes how to start using source control in the Visual Studio 2005 Team System integrated development environment (IDE). In particular, you can learn how to complete the following tasks:

Set Team Foundation as your default source control plug-in for Visual Studio 2005.
Create a new project in Visual Studio.
Add the project to source control and thereby create a local workspace in which to store, edit, and test your source-controlled files.
Check in your solution.
Add a file to the source-controlled project and edit an existing one.
Commit all pending changes in the local workspace to the source control server.

Prerequisites

Before you can complete this walkthrough you must:

Specify a Team Foundation Server. For more information about how to connect to a Team Foundation Server, see How to: Connect to Team Foundation Server.
Create or open an existing team project. For more information, see Walkthrough: Creating a New Team Project or Walkthrough: Joining a Team Project.

Required Permissions

To complete this walkthrough, you must have the Read and Checkin permissions. For more information, see Source Control Security Rights and Permissions.

Set Team Foundation Source Control as the source Control Plug-in

Before using Team Foundation source control, you must configure Visual Studio to use the Team Foundation source control plug-in as demonstrated in the following procedure. For more information, see How to: Configure Visual Studio with Team Foundation Source Control.

Note

By default, Team Foundation source control should be configured when Team Explorer is installed after Visual Studio.

To configure Visual Studio to use Team Foundation source control

On the Tools menu, select Options.
In the Options dialog box, locate Source Control, expand it, and then click Plug-in Selection.
In the Current source control plug-in drop-down list box, select Visual Studio Team Foundation Server.
Click OK.

Add a Project to Source Control

Before adding a project to Team Foundation source control, you must open an existing team project. For more information, see Walkthrough: Joining a Team Project. If you do not have an existing project, see Walkthrough: Creating a New Team Project to create one.

The first time that you add a project to source control, a workspace is created for you. A workspace is a client-side copy of the files and folders on the Team Foundation server. When you add, edit, delete, move, rename, or otherwise manage any source-controlled item, your changes are persisted, or marked as pending changes, in the workspace on the local computer.

A workspace gives you an isolated space where you can write and test your code without concern about how your modifications affect the stability of checked-in sources or how you might be affected by changes that your teammates make. Pending changes are isolated in a workspace until you commit them to the Team Foundation server by checking them in.

You can create more than one workspace on your computer for each Team Foundation server. For more information, see Working with Source Control Workspaces.

To create a new solution and project

On the File menu, click New, and then click Project.
In the New Project dialog box, select Visual C# in the Project Types pane.
In the right pane, click Windows Application.
In the Name box, type MyWindowsApp, type a path in the Location box, and then click OK.

The following procedure describes how to add your new solution to source control and assumes that you have connected to Team Foundation Server from the current computer. If you want more information about connections, see How to: Connect to Team Foundation Server.

To add the solution to source control

In Solution Explorer, right-click the solution and select Add Solution to Source Control.
In the Add Solution to Source Control dialog box, locate where you want to add the project or solution under Team Project Location and either accept default values or click Make New Folder, and enter the desired folder name or change the name of the solution folder in the Choose a name for the solution folder text box.

Note

You can optionally click Advanced and select an alternative mapping for the solution. . For more information, see How to: Choose an Alternate Mapping for a Solution.
Click OK.

After you commit the addition by performing a check-in, the solution is added to the source control server. For more information, see Submitting Changes to the Source Control Server.

Note

Solutions and projects can also be added from the command line or from the Visual Studio menu; however, adding projects and solutions in these ways does not bind them. This binding is responsible for providing source control functionality including various source control icons that indicate status in Solution Explorer For more information, see How to: Bind and Unbind Projects and Solutions, Add Command and How to: Add Non-Project or Non-Solution Files and Folders to Source Control.
From the Build menu, click Build Solution to confirm that the application builds without error.

Warning

Get the latest version of all relevant sources from the server and compile your code to make sure that it builds without error before checking in pending changes. In this case however, your pending changes are all additions that do not yet exist in the server. Therefore, you do not have to perform a Get Latest operation.
If the Pending Changes window is not currently open, on the View menu, point to Other Windows and then click Pending Changes. In the Pending Changes dialog box, click Check In to check in the pending add changes to the server, for more information, see Pending Changes and How to: Check In Pending Changes.

Pending Changes Window

You can think of the Pending Changes window as the source control command console; it centralizes information about the status of your project and provides access to contextually-relevant source control, and work item management information and commands. If you close your Pending Changes window, you can restore it from the View menu. For more information, see Using the Check In and Pending Changes Windows.

Edit the Source-Controlled Project

Source control is a fully integrated part of Visual Studio development. When you add a file to a source-controlled project for example, Visual Studio silently checks out and automatically updates the project file.

When you add a file to a source-controlled project, Visual Studio assumes that you intend to edit the file in some way before making the file available to your teammates. Therefore, newly added files are not checked in automatically but are treated as pending additions to source control until you explicitly check in your uncommitted changes and thereby create a new changeset in the server

To add a file to a source-controlled project

Right-click the project in Solution Explorer, click Add, and then click Class.
In the Add New Item dialog box, click Add to add Class1.cs to your project.

Class1.cs appears together with the other project files in the Pending Changes window and its Change type is add. In Solution Explorer, you can see that the project's signal icon has changed from a blue lock to a red check mark. This icon indicates that the project file is checked out. You might also notice that Class1.cs is displayed with a plus (+) symbol that denotes a pending addition.

By default, the file is automatically and silently checked out when you choose to edit a project file that is checked in.

To edit an existing file in a source-controlled project

In Solution Explorer, in the Properties folder, double-click AssemblyInfo.cs.
Add a new using directive such as using System.IO.Ports; to the file in the code editor.

Note that AssemblyInfo.cs is checked out automatically when you start to edit it. In Solution Explorer, its signal icon is changed to a check mark and the file is added to the source files list in the Pending Changes window.

Synchronize Your Workspace with the Latest Server Version

Perform a Get Latest operation to synchronize your workspace with the latest server version and then build your project before checking it in. If you always synchronize and build before checking in, you can avoid integration build breaks that occur when you and another user check in non-conflicting but mutually incompatible changes which in combination prevent your application from compiling.

To synchronize your workspace to the latest server version and build

In Source Control Explorer, right-click the solution in Solution Explorer, and then click Get Latest Version.
On the Build menu, click Build Project, where Project is the name of your project. In this case, MyWindowsApp.

Check In Your Pending Changes to the Server

After making sure that your application builds with the latest version, you can check in your changes to Team Foundation source control and make the project visible to your teammates.

Note

If your application does not build, if you have not had time to test it for some reason, or if you want to share your code for review by another developer, you can shelve your changes instead of checking in. For more information, see Working with Source Control Shelvesets.

You can check in pending changes in the following ways:

Using the Source Control submenu of the File menu.
Right-click a checked-out file in Solution Explorer or Source Control Explorer.
Click Check In, in the Pending Changes window.

To quickly check in all pending changes to the server

On the View menu, click Pending Changes.
In the Pending Changes window, type a comment in the Comment box to explain the nature of your changes such as "added using directive" and why you made them for example, "to enable calls to the Directory class".
Open the Work Items channel and select any work items that are relevant to your pending changes. For more information, see How to: Associate Work Items with Changesets.
Open the Check-in Notes channel and fill in comments for the check-in notes for the Code Reviewer, Security Reviewer, and Performance Reviewer.

Note

Check-in notes can be configured as mandatory fields by an administrator and must be completed during the check-in process. Mandatory fields are indicated by the shaded color in the text box background.

For more information about how to create check-in notes and create custom work item transitions, see Walkthrough: Customizing Check-in Policies and Notes.
Click Check In.

The Team Foundation Server check-in process is designed for individual ease of use and team extensibility. To optimize ease of use, the Pending Changes window implicitly assumes that you want to check in all changes. However, you can easily exempt individual pending changes from being checked in. Check-in generally applies sets of related changes instead of individual ones. Conversely, when you check in from Solution Explorer or the File menu, Visual Studio assumes that you only want to check in changes to the selected item unless the selected item is a file container such as a project or solution.

A Team Foundation Server administrator can associate a set of custom check-in policies with a team project to make sure that all check-ins meet specific guidelines or requirements.

Individual team members can create work items to track product defects or feature requests and associate a work item with a specific project. When you complete a work item, you can associate it with the source changes by marking it as such on the Work Items channel in the Pending Changes window. Associating work items with source changes makes sure that you enable accountability and tracking of work status.

Finally, you and your teammates can add meaningful and consistent notes to each check-in. The process template used to create the team project determines the form and content of check-in notes and can be customized by the Team Foundation Server administrator. Categories of Check-in Notes can include the following: performance impact, documentation requirements, test instructions, and build instructions.

The Check-in Process

When you click Check In, the selected source files are bundled together with any check-in notes and work items that you specified in the Pending Changes window. This bundle is then uploaded to the Team Foundation server where the bundle is committed as a new changeset. A changeset* *is a set of file revisions, check-in notes, associated work items, and source control metadata that is stored on the server as a single, easy to manage entity. For more information, see Working with Source Control Changesets.

Second, any work items that are included in the changeset are updated to contain links back to the newly created changeset.

Next, work items are transitioned through a workflow based on any predefined processing rules that exist. For example, your team might define a rule that automatically changes the status of a bug from "Active" to "Resolved" if its substatus is "Fix Available" when you check in the bug. The processing rules and workflow are created by the process template used to create the team project, but they can be modified or customized by the Team Foundation Server administrator. For more information, see Customizing Process Templates.

Finally, an e-mail notification is sent to all team members who have subscribed to check-in notifications.

Next Steps

After you complete the steps in this walkthrough, you can try some advanced functionality in Team Foundation source control by continuing on with Walkthrough: Advanced Functionality of Source Control. This walkthrough covers branching, merging, and applying labels to source control items.