Team Foundation Version Control Essentials

In this section, you learn some of the basics of interacting with Team Foundation Version Control. You've already seen the basics of checking items in and out and branching and merging, so that will not be repeated here.

Here you learn how to add version control to a team project, how to add files to version control, and security considerations. You look at the Source Control Explorer, shelving, and check-in policies.

Configuring Team Foundation Version Control

To get started using Team Foundation Version Control, you need to set up your team projects to have access to the version control system. Once they have access to the system, then you can begin to add items into version control, enabling you to track changes made to objects in the system. Configuring your access to Team Foundation Version Control is relatively simple, and can be done from the GUI or the command-line interface.

Adding Version Control to a Team Project

There are two ways to add version control to a team project. You can associate the team project with the version control system when you initially create the project, or you can do it at a later point and time.

Figure 12-14 shows the Specify Source Control Settings windows, which is one of the steps in the Team Project Creation Window.

Figure 12-14

You have three options for specifying your source control during the creation of your team project. You can choose to create an empty source control folder. This folder will default to the name of your team project, and will be located right off the root of the repository, represented by a $. The second option is to choose to create a branch from an existing area of the repository. Using the drop-down list box, you can select which area you want to branch from. This will create a new folder in the repository off the root of the repository, with the same name as the team project you are creating. However, the difference between this and the first option is that this project is a branch off an existing folder, so it includes the latest version of all the files in the folder. The third option is to not create a source control folder at this time. This creates your team project, but does not associate it with the version control repository. As you will see shortly, you can then manually associate the team project with the version control system.

If you choose not to associate your team project with the version control system at creation time, you can do it at any point in the future. Simply open Team Explorer, navigate to your project, and double-click Source Control. You will be asked if you want to create a folder for this team project at $/<Team Project Name>.

Adding Source Files to Version Control

To add source files, follow these steps:

1. Open Visual Studio 2005 and create a new console application (File ⇨New ⇨Project⇨Visual C# Console Application) and name it ConsoleApplication1. Figure 12-15 shows you the New Project creation window.

2. When you create a new project, not a team project but a regular development project, you can choose to add it to source control at the time the project is created. Simply click the Add to Source Control check box. This opens another window, where you select the team project and the folder you want to add your development project to, as shown in Figure 12-16.

   As you can see from the figure, you are adding the ConsoleApplication1 project to the BaseTeamProject Team Project. By default, a folder is created under the team project called ConsoleApplication1. You can add folders under the listed team projects by clicking the Make New Folder button. You can also type in a different name for the solution folder if you would like.

3. Go ahead and change the name for the solution folder to be MyConsoleApplication1. The solution and project files are added to the $/BaseTeamProject/MyConsoleApplication1. Click OK to finish creating the project.

4. You have now added the ConsoleApplication1 development project to the Team Project named BaseTeamProject. Notice in the Solution Explorer, as shown in Figure 12-11, that all the files in the project have a plus sign beside them, as was discussed earlier. To check these files in, open the Pending Changes window and click the Check In button.

Figure 12-15

Figure 12-16

If you choose to add an application to source control later, you simply right-click the solution node in Solution Explorer and select Add Project To Source Control. This opens the window shown in Figure 12-16, where you can follow the same steps.

Important

You can associate multiple development projects with a single team project. It is not just a one-to-one correspondence. In fact, it is expected there will be multiple solutions under each team project.

Security Considerations

From a security perspective, you can set important permissions on a global and a project scale. The global permissions a user can have for the version control system are:

• Administer shelved changes - This gives the user the ability to delete shelvesets that have been created by other users.

• Administer workspaces - This gives the user the ability to create and delete workspaces for other users.

• Create a workspace - This gives the user the ability to create a workspace for themselves.

Depending on the organization of your team, you may want to have multiple people with the ability to work with workspaces and shelvesets, so that you do not end up waiting for one person to administer your workspaces and shelvesets.

Besides these global permissions, you can set security levels at a team project level, a folder level, or even an individual file level. You will explore this more in the next section concerning the Source Control Explorer.

Source Control Explorer

The Source Control Explorer is the main access point into Team Foundation Version Control. The Source Control Explorer is integrated into the IDE, making it very easy to find and use. To open the Source Control Explorer, you can either double-click the Source Control icon in a team project, or select View⇨Other Windows⇨Source Control Explorer. Figure 12-17 shows the Source Control Explorer.

Figure 12-17

Once you are in the Source Control Explorer, you have several different options available to you. You can manage your workspaces as was discussed earlier in the chapter. You can click the Add Files button to add files to a particular project. You can delete files and folders. You can get the latest versions of a file and store them in your workspace. You can check items in and out.

Important

Make sure your workspace is mapped to the repository and to a local folder. If the option to add files and folders to your project is not available (grayed out) in the Source Control Explorer, then you do not have the appropriate mappings in your workspace.

If you right-click a file, the context menu offers several options. You can choose to get a specific version of a file instead of the latest version. Your options with this include retrieving a file by changeset, date, label, latest version, or workspace version. If you try to retrieve a version that is already located in your workspace, it will not overwrite the version in your workspace, unless you check the Force get check box in the Get window.

You can right-click a file or folder and lock it. You can set it so other uses cannot check a file in or out, or allow them to check a file out, but not check it back in. You can also right-click a file and select Compare. This allows you to compare a file in your workspace with a version of the file from the repository, allowing you to see how the files differ textually. You have already seen earlier how you can branch and merge.

The Source Control Explorer is the main window into the Team Foundation Version Control system. You will probably spend a lot of time here, so take some time to become comfortable with the environment.

Setting Security Using Source Control Explorer

The beauty of using a path-based source control system is that you can set permissions on folders and even individual files. This allows you very granular control over your version control system. To modify the security permissions for a particular file or folder, simply right-click the file or folder in the Source Control Explorer, and select Properties. When the properties window opens, click the Security tab.

On this tab, you can add and remove Team Foundation Server groups, and Windows Users or Groups. You can also specify the permissions for the groups, to either Allow or Deny certain security permissions. By default, if a permission is not set to Allow, it is automatically assumed to be Deny.

Important

Team Foundation Server grants certain access rights to certain groups by default. Be very careful about modifying the rights of these groups.

The following are some of the permissions you can set on a file or folder:

• Read - Read the file

• Check out - Check Out the file

• Check in - Check In the file

• Label - Add a label to a file

• Lock - Lock a file

• Revise other users' changes - Revise committed changes made by other users

• Unlock other users' changes - Ability to remove a lock on a file by another user

• Undo other users' changes - Ability to rollback changes from a user

• Administer labels - Create, delete, and modify labels

• Manipulate security settings - Ability to modify security settings

• Check in other users' changes - Ability to check in changes on behalf of another user

The ability to provide this granular level of control from a security perspective is just one more aspect of Team Foundation Version Control and Team Foundation Server that make it so appealing.

Shelving

Shelving is a new feature to version control and is specific to Team Foundation Version Control. The best way to understand shelving is with an example. Say you are working on a project and are in the middle of adding some new features to the application when your boss walks in and tells you he needs you to fix a bug that has been found. You can't fix the bug in the code currently in your workspace, because when you check the bug fix in, you will also be adding your new features, which may not be ready yet. Normally in this case, you would back up the files you had been working on, delete them from your working directory, download the old code, fix it, check the bug fix back in, then restore the files you had been working on - a rather cumbersome process.

Shelving automates this process for you. Using shelving, you can automatically store what you have been working on onto Team Foundation Server. It does not check the files back in, but it moves them to the Team Foundation Server. This allows you to then download the old code into your workspace and make the changes. Then, when you are done, you can unshelve your new code back into your workspace.

Besides the bug fix scenario described, here are some reasons you might want to shelve your code:

• You may not be finished with some coding changes before you go home, but you want to make sure your code gets backed up, so you shelve it to TFS to have it backed up in the nightly backup.

• You want someone else to review your new code. You shelve your changes, and another developer unshelves them and does a code review. Then that developer can check the changes in if they pass.

Shelving your pending changes is easy. In the Pending Changes window, just click the Shelve button. You enter a name for your shelveset, an optional comment, and select the items you want to shelve. You can also associate the shelved items with work items at this stage. You also have the option of keeping your pending changes in your workspace, or undoing them as part of the shelving process. Once you are ready, click the Shelve button to shelve your changes. You can create as many different shelvesets as you would like.

To unshelve a shelveset, simply open the Pending Changes window, and click the Unshelve button. This opens the Unshelve window, as shown in Figure 12-18.

Figure 12-18

In this window, you can search for the shelvesets that have been created by a particular user. Once you have found a shelveset, you can click the Details button to view the files contained in the shelveset. You can also delete the shelveset, or unshelve it to your workspace.

Setting Source Control Options

You can specify Source Control Settings on a per team project basis. Right-click your team project in Team Explorer, and select Team Project Settings⇨Source Control. This opens the Source Control Settings window for your team project.

There are three tabs on this window. The first tab is the Check-out Settings tab. This tab allows multiple check-outs, or shared check-outs. By default, this is allowed. You can deselect the check box to turn off shared check-outs.

The second is the Check-in Policy tab. This is where you select which check-in policies you want to apply to your team project. A check-in policy is a way to stipulate requirements for how code is checked into the system. Team Foundation Server ships with the following three check-in policies:

• Code analysis - You must run code analysis before check-in.

• Testing policy - Tests must be successfully executed before check-in.

• Work items - Work items must be associated with check-in.

Besides the shipped policies, you can create your own, as you learn to do later in this chapter.

The final tab is the Check-in Notes tab. This tab allows you to add or remove items from the Check-in Notes page. By default, there are three titles on this page: Code Reviewer, Security Reviewer, and Performance Reviewer. You can also make these fields required, meaning that someone has to add their names to these fields before the check-in can occur.

You can also elect to be notified via e-mail anytime an item is checked in. To do this, right-click your Team Project and select Project Alerts. This opens the Project Alerts window, as shown in Figure 12-19.

Figure 12-19

As you can see, you can sign yourself up for several different notification events. To be alerted anytime something is checked in, simply check the Anything is checked in check box, and enter your e-mail in the Send to box.