Walkthrough: Exploring Team Foundation Version Control

  • Article

This walkthrough demonstrates version control integration features in Visual Studio Team System Team Foundation Server.

This walkthrough describes how to use version control in the Visual Studio Team System Team Foundation Server IDE. In particular, you can learn how to complete the following tasks:

  • Set Team Foundation version control as your default version control plug-in for Visual Studio Team System Team Foundation Server.

  • Create a new project in Visual Studio.

  • Add the project to version control and thereby create a local workspace where you can store, edit, and test your version-controlled files.

  • Check in your solution.

  • Add a file to the version-controlled project and edit an existing one.

  • Commit all pending changes in the local workspace to the version control server.

Prerequisites

Before you can complete this walkthrough, you must:

Required Permissions

To complete this walkthrough, you must have the Read and CheckIn permissions.

Set Team Foundation Version Control as the Source Control Plug-In

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

Note

Visual Studio is configured to use the Team Foundation version control plug-in automatically when Team Explorer is installed after Visual Studio is installed.

To configure Visual Studio to use Team Foundation version control

  1. On the Tools menu, select Options.

  2. In the Options dialog box, locate SourceControl, expand it, and then click Plug-in Selection.

  3. In the Current source control plug-in drop-down list, select Visual Studio Team Foundation Server.

  4. Click OK.

Add a Project to Version Control

When you create projects, you might want to add them to version control so you can manage them in Team Foundation version control. The first time that you add a project to version control, Team Foundation version control creates a workspace for you. A workspace is a client-side copy of the files and folders stored on the server that runs Team Foundation Server. When you add, edit, delete, move, rename, or otherwise manage any version-controlled item, your changes are persisted on the client. They are tracked as pending changes in the workspace on the local computer.

A workspace provides an isolated space where you can write and test your code. Your modifications do not affect the stability of checked-in sources. You are isolated from changes that your teammates make. Pending changes are isolated in a workspace until you commit them to Team Foundation by checking them in.

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

To create a new solution and project

  1. On the File menu, click New, and then click Project.

  2. In the New Project dialog box, select Visual C# in the Project Types pane.

  3. In the right pane, click Windows Forms Application.

  4. In the Name box, type MyWindowsApp, and then type a path in the Location box.

  5. Select the Add to Source Control box, and then click OK.

  6. In the Add Solution to Source Control box, select the team project that you want to use for this walkthrough.

  7. Click OK.

You can also add solutions and projects from the command line or from the Visual Studio menu. However, adding projects and solutions in this way does not bind them. Binding provides version control functionality. This includes various version 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 Version Control.

Pending Changes Window

The Pending Changes window provides information about the status of pending changes in your workspace. Use it to keep track of information associated with your changes such as relevant work items and check-in notes. You can use the View menu to access the Pending Changes window. For more information, see Using the Check In and Pending Changes Windows.

Note

You should 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.

Next, you must use the Pending Changes window to check in your new solution files to version control.

To check in pending changes for the solution to version control

  1. From the Build menu, click Build Solution to confirm that the application builds without error.

  2. If the Pending Changes window is not open, on the View menu, click Other Windows and then click Pending Changes.

    The Pending Changes window will list your solution files as add. This means that the files are created in your workspace, but have not been added to the server yet.

  3. In the Pending Changes window dialog box, enter the comment "Adding new project to version control" in the Comment box.

  4. 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. For more information, see Submitting Changes to the Version Control Server.

Edit the Version-Controlled Project

Version control is a fully integrated part of Visual Studio development. For example, when you add a file to a version-controlled project, Visual Studio silently checks out and automatically updates the project file.

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

To add a file to a version-controlled project

  1. Right-click the project in Solution Explorer, click Add, and then click Class.

  2. 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. Note that Class1.cs appears with a plus (+) symbol; this indicates a pending addition.

Files are automatically and silently checked out when you decide to edit a project file that is checked in.

To edit an existing file in a version-controlled project

  1. In Solution Explorer, in the Properties folder, double-click AssemblyInfo.cs.

  2. Add a new using directive such as using System.IO.Ports; to the file in the code editor.

Note that Team Foundation checks out AssemblyInfo.cs automatically when you start to edit it. In Solution Explorer, its signal icon is changed to a check mark. The system adds the file to the source files list in the Pending Changes window.

Synchronize Your Workspace with the Latest Server Version

You use the Get Latest operation to keep files in your workspace synchronized with the latest server version. If you always synchronize and build before checking in, you can avoid breaking the integration build. You can break a build when you and another user check in non-conflicting but mutually incompatible changes that together prevent your application from compiling.

To get the latest version from the server to your workspace and build

  1. Right-click the solution in Solution Explorer, and then click Get Latest Version (Recursive).

  2. From the Build menu, click Build Solution to confirm that the application builds without error.

Check In Your Pending Changes to the Server

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

Note

If your application does not build because you did not have time to test it, or if you wanted to have your code reviewed by another developer, you can shelve your changes instead of checking them in. For more information, see Working with Version Control Shelvesets.

You can check in pending changes in the following ways:

  • Use 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 check in all pending changes to the server

  1. On the View menu, click Other Windows, and then click Pending Changes.

  2. In the Pending Changes window, type a comment in the Comment box to explain the nature of your changes.

    For example, you could type "added using directive" and, to indicate the reason, "to enable calls to the Directory class".

  3. 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.

  4. Open the Check-in Notes channel and add 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. They must be completed during the check-in process. The shaded color in the text box background indicates which fields are mandatory.

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

  5. 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 from the File menu, Visual Studio assumes that you only want to check in changes to the selected item. When you select a file container such as a project or solution, you are selecting for check-in that item and the items it contains.

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

Individual team members can create work items to track product defects or feature requests. They can 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. When you associate work items with source changes, you guarantee accountability and careful 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 your check-in notes. The Team Foundation Server administrator can customize the template for your team. Categories of check-in notes can include performance impact, documentation requirements, test instructions, and build instructions.

The Check-In Process

When you click Check In, the system bundles together the selected source files with any check-in notes and work items that you specified in the Pending Changes window. Team Foundation version control then uploads this bundle to Team Foundation and commits the bundle as a new changeset. A changeset is a set of file revisions, check-in notes, associated work items, and version control metadata that is stored on the server as a single, easy-to-manage entity. For more information, see Working with Version 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 that was used to create the team project. However, the Team Foundation Server administrator can customize the rules and workflow. For more information, see Customizing Process Templates.

Finally, Team Foundation version control generates an e-mail notification to all team members who want check-in notifications.

Next Steps

After you complete the steps in this walkthrough, you can learn more about advanced functionality in Team Foundation version control. For more information, see Walkthrough: Advanced Functionality of Version Control. This walkthrough shows you how to branch, merge, and apply labels to version control items.

See Also

Tasks

Walkthrough: Creating a New Team Project

Concepts

Using the Check In and Pending Changes Windows

Other Resources

Team Foundation Version Control Walkthroughs

Working with Team Foundation Version Control