Chapter 3

Team Foundation Version Control

What's In This Chapter?

• Understanding Team Foundation version control
• Setting up version control
• Using the Source Control Explorer
• Understanding basic version control operations
• Understanding check-in policies
• Viewing the history of files and folders
• Understanding labels
• Understanding shelvesets
• Understanding workspaces
• Getting to know the command-line

If you are a developer you live in a world of source code. When you have more than one person working on a project, versioning becomes an issue. If two developers work on the same assembly, how do you merge their code? How do you prevent accidentally overwriting files? Incredibly, although the practice is rapidly declining, many organizations still just use file shares to store source code. If you are unfamiliar with version control, you can think of it as a filesystem with an extra dimension—time. You are able to share the current state of any file or folder with your team members, but you can go back in time to see what other versions have existed and what the source code looked like at any point in the history of the source code repository.

One of the key reasons you are likely to have chosen Visual Studio Team Foundation Server 2012 is its version control management system. It offers a number of features, including the capability to branch, merge, and shelve your source code, atomic check-ins, policies, security—all the features you expect from an enterprise version control solution. The core engine for this tool is Microsoft SQL Server so you can rely on the resilience of this proven database engine for the integrity of the data stored in it, the procedures and processes to back it up, and the scalability solutions that it provides.

As well as the built-in integration to Team Foundation Server provided as part of the Visual Studio 2012 installation experience, the Team Foundation Server command line (tf) is also installed to enable you to perform version control operations from a command line if you prefer. There is a Windows Explorer shell extension available as a Team Foundation Server Power Tool. You can also access Team Foundation Server from Eclipse using the free Team Explorer Everywhere plug-in. Team Explorer Everywhere is also where you look to find a version of the Team Foundation Server command-line client for non-Windows systems such as Mac OS X, Linux, Solaris, and other flavors of Unix.

Team Foundation Server provides a centralized version control system—that is, there is a single master repository on which you back up, manage, maintain, and control permission. The server has a highly flexible path-based permission system, with access protected by the same Active Directory login used to authenticate with Windows.

Team Foundation Server 2012 introduced a new mode of working—a concept known as Local Workspaces. In previous versions of TFS Server Workspaces (where the state about which files are checked out and so on is stored on the server) were the only option, but the introduction of Local Workspaces stores the state of the files in the workspace on the local filesystem, meaning that you do not have to be connected to TFS to edit a file. Local Workspaces are the default workspace type in Team Foundation Server 2012, so this chapter begins with the assumption that you are working with a Local workspace. Later on in the chapter we discuss both Local and Server workspaces, the differences between them, and which type is suitable for which method of working. In Team Foundation Server 2012 there have been many other improvements in version control as part of the most recent release to make the version control experience more transparent for developers and to reduce friction for developers doing everyday work. The user experience for version control has also been dramatically changed from previous versions—making use of the new unified Team Explorer view for the majority of common version control operations.

In this chapter, you find out about the main features of Team Foundation Version Control, such as checking in and checking out code, setting check-in policies, and temporarily shelving your code for easy access at a later date. The Team Foundation version control system also supports a number of other features, such as atomic check-ins, workspaces, and changesets, all of which are covered in this chapter.

Team Foundation Version Control and Visual SourceSafe (VSS) 2005

Visual SourceSafe (VSS) 2005 reached the end of mainstream support in 2011 and extended support will end in 2016. No new versions of the product will be released. With the 2012 release of Team Foundation Server, Microsoft has made several changes to both the product and its licensing to make it suitable for all sizes of development teams.

Team Foundation version control is part of a greater Software Configuration Management (SCM) solution. Unlike VSS, Team Foundation version control is designed to scale to large development teams and can support distributed and outsourced teams in remote locations. Plus, you can avoid problems such as the occasional corruption of your source code files (because the data is written to a real database, rather than flat files).

Like VSS before it, Team Foundation Server is now available in all MSDN subscriptions including Visual Studio. Team Foundation Server is available for significantly less cost than VSS ever was, yet it is a much more modern, full-featured product with a healthy community and significant on-going investment from Microsoft. Therefore, it is now time to move away from any existing VSS databases toward Team Foundation Server. Fortunately, Microsoft has made it even easier to upgrade a VSS repository into Team Foundation Server by providing a new wizard based solution for performing a VSS migration (with history if required). For more information on using the new Visual SourceSafe upgrade wizard with Team Foundation Server 2012 see http://aka.ms/vssUpgrade.

Setting Up Version Control

Assuming that you've never used a version control system, where do you start? Even if you have used other version control systems, all version control systems work in slightly different ways and have a different model for working with files, so how do you effectively set up and use Team Foundation version control? Let's walk you through the process step-by-step.

After you have connected to your Team Foundation Server project collection, you can create a new team project by clicking File ⇒ New ⇒ New Team Project. This is typically done by your Team Foundation Server administrator, but at this point you are offered a series of options. You get two version control options to set up a new parent folder, as shown in Figure 3.1.

Figure 3.1

In this window, you have the following two options:

• You can create a brand-new parent version control folder (based on the name of your project). For most occasions, choose this option.
• You can create a branch based on a pre-existing project. This option is especially compelling if you want to create another version of an existing application or implement a new process to develop an existing application. However, unless you really know that you want to do this, you can safely go with the first option.

Using the Source Control Explorer

The Source Control Explorer is similar to other explorers in Visual Studio. It enables you to browse and manage the entire version control repository, as well as view projects, branches, and individual folders. You can add and delete files; check in, check out, and view any of your pending changes; and view the status of your local code compared to the code in Team Foundation version control. Think of it as your master control area for all tasks related to source code management. Following are some of the important tasks it enables you to do:

• Map folders
• Add files
• Get files
• Check in changes
• Create shelvesets
• View historical data
• Branch and merge
• Compare files and folders
• Label your files and folders
• Change security settings for files and folders

Many of these topics are examined later in this chapter. To access the Source Code Explorer, simply click View ⇒ Other Windows ⇒ Source Control Explorer. Alternatively there is a shortcut link to the Source Control Explorer on the Team Explorer Home page.

Another way you can open a solution from version control in Visual Studio is by clicking File ⇒ Source Control ⇒ Open from Source Control. Visual Studio prompts you to connect to the Team Foundation Server and select the source code repository of your choice if you are not connected.

Figure 3.2 shows the Source Control Explorer interface. It is divided into three main areas: the source tree view on the left (which enables you to navigate and select source folders from your project), the details view on the right, and the source location bar and version control toolbar at the top.

Figure 3.2

The Source location shows the server path of the currently selected folder in the Source Control Explorer. In Team Foundation Server version control, server paths are given in the format $/TeamProjectName/FolderPath/File.txt where the path separators are a forward slash (/) and the root of the repository is represented by the dollar symbol ($).

Setting Up Your Workspace

Your workspace represents the local working copy of files on your filesystem. You can think of a workspace as your personal sandbox to work on source code; it is the bridge between code on the server and your client machine. A workspace has one or many folders mapped in Team Foundation version control with your local filesystem. Whenever you get files, they are downloaded from the repository in Team Foundation Server and placed into your workspace for you to work on them. To get your changes back into the server repository you check in (commit) the changes. Workspaces provide isolation; they enable you to work on your code to make up your application without affecting any changes the rest of your team might be making.

The workspace itself is bound to a machine and owner. If you move to a different machine you have to create a new workspace. Files that you have edited in your workspace live on the associated machine only. This is an important difference to keep in mind with some other version control systems.

In Team Foundation Server 2012, when you first attempt to access version control operations on the server (such as using Source Control Explorer to browse the contents of the server repository), a Local workspace is created that is automatically ready for you to begin mapping folders and getting files. By default the workspace name is the same as your computer name. However, you can have multiple workspaces belonging to the same user on the same machine and you can swap between them using the Workspace drop-down in the version control toolbar in Source Control Explorer (refer to Figure 3.2).

Getting Existing Code

If you are connecting to a repository that already has code in it, the first thing that you probably want to do is to map a folder to your local filesystem and download the code. Browse to the folder that you would like to map (such as the $/FabrikamFiber/Main folder shown in Figure 3.2). At the top of the details pane on the right side you can see that the Local Path is Not Mapped and that is underlined. Click the Not Mapped link to open the Map dialog and point it at a directory on your local filesystem, as shown in Figure 3.3. Note that the Local Path (or indeed the Server Path) does not need to exist. If the local folder entered into the dialog does not exist then Team Foundation Server attempts to create it for you when you download (or Get) the files for the first time.

Figure 3.3

Whenever you create or change your working folder mappings, Team Foundation Server prompts you if you would like to perform a Get so that the files on the server are downloaded locally as shown in Figure 3.4. Select Yes in the dialog, and the latest version of the Main folder is downloaded into the directory specified.

Figure 3.4

The Local Path in the details pane of Source Control Explorer now shows the path that you are currently viewing, and clicking on the path link opens that directory in the local filesystem. The files in Source Control Explorer are also now in black text rather than gray to show that you have a local copy and the Latest column says Yes.

Sharing Projects in Version Control

If you are sharing new code with your team using Team Foundation Server for the first time then you can import the associated source files into the repository in a number of ways. The process of sharing code in Team Foundation Server is called checking in.

Sharing a Solution in Visual Studio

To share a solution in Visual Studio, right-click the solution in Solution Explorer and select Add Solution to Source Control. If you are not already connected to a Team Foundation Server project collection you select the server and project collection that you want to connect to. Then you select the location in the central version control repository that you want to use for sharing your source code.

If you are sharing code into a new Team Project then a good practice is to create a folder called Main under your Team Project and share the solution into it as shown in Figure 3.5.

Figure 3.5

After you have set the location you want to use for sharing your files, click the OK button on the Add Solution to Source Control dialog window. The solution displays in Solution Explorer with a plus symbol to the left of it (see Figure 3.6). The plus sign indicates that the file is pending addition into version control.

Figure 3.6

This solution is not yet shared with Team Foundation Server. TFS Version Control works using a two-phased process. You first build up a list of changes that you want to make in version control and then you commit the changes in a single transaction called a changeset.

To check the files into version control, go to the Pending Changes page in Team Explorer by right-clicking on the solution in Solution Explorer and selecting Check In. Alternatively you can go to the Team Explorer view and then select the Pending Changes page. A third alternative is to go to View ⇒ Other Windows ⇒ Pending Changes.

The next section reviews the pending changes page. You commit your changes from there.

Sharing a Project in Eclipse

Microsoft provides an Eclipse plug-in as part of Team Explorer Everywhere. After you have the TFS Plug-in for Eclipse installed, you may share a project in Eclipse easily. Right-click the project in Package Explorer and select Team ⇒ Share Project. The Share Project Wizard shows the installed team providers in your Eclipse instance (see Figure 3.7).

Figure 3.7

Select Team Foundation Server and then choose the project collection that you want to connect to (if you have not already connected) and then select the desired TFS workspace. (You can also press Next to select the default TFS workspace, which is usually correct.) The Share Location page of the Share Project Wizard displays as shown in Figure 3.8. From here you select a path in version control to share the files. As previously discussed you want to add your files into a folder called Main, so you simply enter the full server path into the Project folder path text box that you want to share at. As mentioned earlier in the chapter, it does not matter that the Main folder does not exist yet; it is automatically created on the server when you perform the check-in.

Figure 3.8

Pressing Finish creates pending ads for all the files in the project into version control. The file icons are annotated in the Package Explorer with a small check mark to indicate that they are pending adds to version control (see Figure 3.9). Note, just as with Visual Studio, these files are not yet stored on the server; you must first check them in. To get the pending changes view in Eclipse, go to Windows ⇒ Show View ⇒ Other Windows ⇒ Team Foundation Server ⇒ Team Explorer and click the Pending Changes page.

Figure 3.9

In the next section, you find out how to work with the pending changes view to check in code to the source repository. You also find out about changesets and how to configure team check-in policies.

Check-In Pending Changes

Frequent check-ins and gets are an essential part of a developer's workflow. You need to check-in the code so that it is shared with the rest of your team, and you need to frequently Get Latest so that you are developing and testing against the very latest version of the source code that makes up your application.

When making changes in your Local workspaces, Team Foundation Server maintains a list of the files that are being changed and their change types (that is, add, edit, rename, delete) in the pending changes window.

This is one area where the experience in Team Foundation Server 2012 is very different from previous versions. Rather than have another view active in Visual Studio or Eclipse, Microsoft moved the pending changes experience into Team Explorer (see Figure 3.10) to allow more space in the development environment for the code editing window. The pending changes experience was also changed from a horizontal view to a vertical one as part of the move to the new Team Explorer. This was reflective of the fact that most developers now use monitors with a widescreen aspect ratio, so space to the sides of the code being edited is usually available.

Figure 3.10

Checking In an Item

A changeset contains all of the information related to a check-in, such as work item links, file revisions, notes, policies, and owner and date/time details. Team Foundation version control bundles all the information into this logical container. A changeset is created after you check code into the repository, and, as a container, it reflects only the changes you checked in. You can also view it as the state of the repository at a particular moment in time of the repository. The usefulness of a changeset comes from the fact that you can, on a very atomic level, return to any moment of change and troubleshoot your code.

The Pending Changes page, shown in Figure 3.10, enables you to view all of the files in your workspace that Team Foundation Server considers changed from the latest version that you copied into your workspace from the server. You can access this list at any time via Team Explorer or via the View ⇒ Other Windows ⇒ Pending Changes menu option.

The pending changes view shown in Figure 3.10 highlights most of the key areas. In addition to the areas shown, there is also a notification area at the top of the page that is used to inform you when you have successfully checked in changes, so that you know that they are stored on the server. It also gives you a quick reference to the changeset ID that was created.

At the top of the page you see any policy warnings that are currently being given. Check-in policies are covered later in this chapter, but in simple terms you can think of them as code that runs on the client to validate whether a check-in is valid.

Next there is an area to provide a comment. Best practice is that you should provide a short but meaningful comment with every check-in, ideally explaining why you made the changes you are making—not what you changed. To see what you changed, any authorized user can simply look at those changeset details and compare (or “diff” as it is sometimes called) the files inside the changeset. However, a changeset comment explaining why you changed those files is very useful to help others understand why things happened the way they did.

Files listed in the Included Changes section are the files that you want to make up your next changeset. These are the files that you are modifying, creating, or deleting as part of the change. For users of older versions of Team Foundation Server, this is equivalent to having a check in the box next to the file in the old Pending Changes view except that the inclusion or exclusion of a file in the pending changes list is now persisted so you no longer accidentally include a file that you thought you had excluded.

Files that are in the Excluded Changes section are those that you have positively modified as part of your changes but you have told Team Foundation Server that you do not want to check them in. Perhaps you have modified a web.config file to enable local debugging or you are still working on some changes and you do not want to check them in yet. If you find that you are frequently having files in the excluded changes window just because you haven't finished working with them then you should consider making use of the Shelvesets feature of Team Foundation Server, which is discussed in the “Shelving” section later in this chapter.

Finally, the Notes section lists the check-in notes that have been configured for the Team Project. Check-in notes are covered in the “Shelving” section later in this chapter. In simple terms check-in notes are additional string-based metadata that you can configure in your repository. The check-in notes can also optionally be specified with one or more of them to be mandatory (such as the Code Review example in Figure 3.10).

In the next section you find out how to associate work items with a particular check-in, which many teams find a good practice to ensure that every change is associated with a particular work item (either a bug or a task). As a result you can have end-to-end requirements traceability (from the initial story, requirement, or product backlog item through to the task to implement it, through to the check-in that provided that feature, and finally to the build in which the feature was included).

Candidate Changes

Before moving from the Pending Changes view, it is worth discussing Candidate Changes, which are a new feature unique to a Local Workspace in Team Foundation Server 2012.

Inside the Excluded Changes section there is a Detected Changes link. Clicking it shows any Candidate Changes that Team Foundation Server has detected (see Figure 3.11). If you have made changes in the filesystem, such as adding or deleting a file outside of Visual Studio, then these changes are not automatically pended by Team Foundation Server. They are flagged as changes that you might want to add into your pending changeset. The example shown in Figure 3.11 shows five candidate changes.

Figure 3.11

In this case, the ui-icons image file was deleted by the developer from Windows Explorer as she realized that the file was no longer needed in the website. The developer renamed bullet.png to wingding.png while she had no network connection to Team Foundation Server and was working offline. The developer added testdata.txt in Windows Explorer as a data file to be used during testing, but she did not specifically add it to the solution, which is why Visual Studio did not explicitly pend an add against it. And finally testrun.dat was automatically created in the source tree as part of a unit test run, and the developer wants to make sure that she and her colleagues never accidentally check in this file.

As the developer renamed the bullet.png file inside Windows Explorer, Team Foundation Server has no way to automatically detect that this was a rename operation. It sees the changes as an add and a delete. If the change had been made inside of Visual Studio from Source Control Explorer or Solution Explorer then the rename would have been automatically detected and pended as such, which would have preserved the history on the file under the new name. The developer would like to preserve that this was a rename operation and selects both bullet.png and wingding.png (by holding down Ctrl while making the selection) and then selects the Promote as Rename option as shown in Figure 3.12. This creates a new pending change on wingding.png specifying that it was renamed from bullet.png.

Figure 3.12

Next the developer wants to ensure that no one ever accidentally checks in the file testrun.dat as this is generated as part of a unit test run and doesn't make up the code of the application. She right-clicks the file and selects Ignore This Local Item (see Figure 3.11). This creates a file in the folder called .tfIgnore that tells TFS to ignore this file from ever being added to version control. Note that the developer could have ignored all files with a .dat extension, or files called testrun.dat regardless of where they appear below the folder containing the .tfIgnore file. She even could have ignored the whole HellWorldMVC.Tests folder. After the .tfIgnore file is checked in to version control, other developers will also ignore that file.

The developer is left with two candidate changes (see Figure 3.13) that are both checked. She clicks the Promote button as she wants to make sure that those candidate changes are included in her next changeset.

Figure 3.13

Performing the Check-in

Figure 3.14 shows that you now have the changes and how you want them recorded. There is a changeset comment, and a work item associated with the check-in will be marked as resolved when you perform the check-in. Click the Check In button and the changes are committed to TFS in a single atomic transaction and given a changeset ID.

Note that if TFS could not have performed the check-in for some reason (perhaps another developer had checked in a conflicting change to the HomeController.cs file while you were editing your version) then none of the changes would have been checked in. You would have been notified about the conflict and given options to resolve the conflict before you were allowed to complete the check-in. Only when all the files included in the changeset can be committed to the repository is the changeset created and given the next incremented changeset ID for that project collection.

Note that as well as checking in from the Pending Changes view, there are a number of other actions on the drop-down menus next to the Check In button. You can shelve or unshelve code, resolve conflicts, undo changes that have in the pending changeset with the version that you last got from the server, manage your version control workspaces, and, if you have an appropriate version of Visual Studio, you can request a code review.

Creating and Administering Check-In Policies

Check-in policies provide a way for the team and individuals to effectively manage quality and workflow to the source management process used by the team. They are implemented as code that is run on the client before each check-in to validate if it is able to occur or not. Because the code is run on the client, check-in policies are configured separately for the .NET-based clients (such as Visual Studio, the Windows Shell Extensions, or the Team Foundation command line on Windows) and the Java-based clients provided by Team Explorer Everywhere (such as the TFS Plug-in for Eclipse or the cross-platform command-line client).

Figure 3.14

As a team project administrator, to configure the check-in policies for Visual Studio users, right-click your Team Foundation project and select Team Project Settings ⇒ Source Control. Under the Check-in Policy tab (see Figure 3.15), you find several options for modifying the check-in policies.

If you click the Add button in the Source Control Settings dialog box (see Figure 3.15), you are prompted to select a check-in policy type. The list shown in Figure 3.15 are those provided out of the box in Visual Studio 2012 (note that the Changesets Comments policy is now in the box, but the Testing Policy is no longer shipped by default). More check-in policies are provided by the Team Foundation Server power tools, and your administrator may have installed further custom check-in policies for your organization. Selecting each of the check-in policies provides more information about it.

Figure 3.15

After the check-in policy has been created, try checking in code without complying with the new policies. The policy failure warning is displayed in the pending changes view as shown in Figure 3.10. Note that for a check-in policy failure warning you have the ability to override it and perform the check-in anyway.

To set the check-in policies for your Team Explorer Everywhere users, a team project administrator should connect to the team project in Eclipse, view the Settings page in Team Explorer, select Check-In Policies, and then enable the desired check-in policies as provided by Team Explorer Everywhere, shown in Figure 3.16.

Figure 3.16

Viewing History

To view the history of a file or folder, in Source Control Explorer, right-click the file or folder and select View History from the context menu. The View History menu option is usually available via a context menu from many other places where the file is shown, such as when you right-click the file itself in the code editor, from Solution Explorer, in the Pending Changes view, and more. Viewing history on a file opens a new document tab, as shown in Figure 3.17.

The History window is now a tabbed document window in Visual Studio and Eclipse. This enables you to open multiple History windows for research. Notice that the window in Visual Studio has two sub-tabs: Changesets and Labels. The History window now gives you a view of both the changesets associated with the file or folder, as well as any labels. Notice that the changeset ID's for a file are not sequential. The changeset ID's are incremented globally to represent a point in time of the entire repository for the project collection. The changeset IDs for the file show the changesets in which that file was modified. This is a different versioning mechanism to systems such as VSS in which individual files have version numbers; in Team Foundation Server the only version number that matters is the changeset ID.

Figure 3.17

You have several options from the Changeset sub-tab. You can select a changeset and click the View button to view the file version for that particular changeset. You can click the Changeset Details button to view the details for a particular changeset, including all the files that make up the changeset and any associated work items. You can compare two different versions of a file or folder to see the differences. Clicking the Annotate button enables you to see, line by line, who made what changes to a particular file. Selecting Rollback reverts all the changes made in that particular changeset. You are able to track the changeset across branches to see if those changes have made it into the other trees of your source code, you can also request a code review if you have an appropriate version of Visual Studio.

Finally, you can select a changeset and click the Get This Version button. This replaces the current version of this file in your workspace with the selected version, enabling you to easily return to an earlier version of a file.

When viewing the history of a single file, the History window also enables you to expand the history of that file prior to a rename or a merge from another branch.

Labeling Files

A label is a marker or a tag that can be attached to files and folders in Team Foundation version control. This marker allows all the files and folders labeled together to be retrieved as one collective unit. Although labels are often generated by things like an automated build, in Team Foundation Server labels are editable by users with the appropriate security permissions. They are not designed to provide auditable points of reference, for that you should make note of the changeset ID as that represents an exact point in time of the source code repository.

To create a new label, in Source Control Explorer, right-click the file or folder you want to label, and select Apply Label from the context menu. The New Label window displays.

In this window, you can enter the label name and a comment. You can also select the version that you want to label. You can choose to label by Changeset, Date, Label, Latest Version, or Workspace Version. Click the Create button to create the label.

Notice next that the Create button is a drop-down arrow. Clicking the arrow provides you with two options. You can create the label as is, or you can create the label and then edit it. If you select Create and Edit, the label is created, and you are presented a new tab, as shown in Figure 3.18.

Figure 3.18

This tab enables you to make multiple changes to the label. You can add new files to the label. You can change the version of a file that the label is currently applied to. And you can remove files from the label. All of this is made easily accessible by using the Tree View control.

Shelving

There are times when you won't be ready to commit your source code into the core repository. For example, maybe you need to go home for the evening but haven't been able to check-in and you want to make sure you have a back-up of your work. Or say that you are working on solving a bug and you want to share the changes you have made with a colleague to get his assistance on a particular issue. Shelving enables you to quickly and easily store files and code aside on the server without committing them to the main code base. The collections of stored pending changes that haven't been committed are called shelvesets.

The process of creating a shelveset is fast and easy. From the Pending Changes page in Team Explorer, click the Shelve link. Enter a name for your shelveset in the box that displays (see Figure 3.19) and the options to preserve the pending changes locally as well as to evaluate the check-in policies and check-in notes before shelving.

Figure 3.19

Shelvesets contain the same level of information as a changeset, including associated work items, comments, and check-in notes. Team Foundation Server is able to store other metadata alongside a shelveset as properties, which are used by the Code Review functionality detailed in Chapter 17. Keep in mind that, unlike with a changeset, the changes are not versioned. Shelvesets can be permanently deleted (which is something you can't do with changesets). You can't link directly to a shelveset from a work item and you can override the data stored in a shelveset at any time by creating a new one with the same name as one created previously by that user.

Unshelving source files is as easy as shelving them. First, bring up the Pending Changes page of Team Explorer and then from the Actions drop-down select Find Shelvesets. By default your own shelvesets are shown as in Figure 3.20, however you can also search for the shelvesets of a team member by entering her username or display name and pressing Enter.

Figure 3.20

From the shelveset results you have the option to view the shelveset details, unshelve those changes into your workspace, delete the shelveset completely from the server, or, in certain versions of Visual Studio, request a code review on the contents of the shelveset.

A new feature in Team Foundation Server 2012 detects and handles conflicts as part of the unshelve process. In previous versions if you had a conflicting change already in your workspace then you would not be able to unshelve the contents of the shelveset. In Visual Studio 2012 and Team Explorer Everywhere 2012, unshelving conflicts are shown in the conflicts editor just like any other merge conflict. In addition, due to the new automerge capabilities in this recent release, the likelihood of getting a conflict on unshelve is much lower (for example two changes to the same file in different places would be automatically merged when you did the unshelve and would not result in a conflict).

Workspaces

As discussed earlier, the majority of this chapter has dealt with using Team Foundation Server version control via a Local Workspace, which is the default option. However, this is a new a different workspace type than was available previously with Team Foundation Server. Table 3.1 describes the two workspace types, how they differ, how your usage of TFS version control changes, and when you would select one workspace type over another.

Table 3.1 Local and Server Workspaces Compared

Note that a Team Project Collection administrator can define which workspace type is the default for projects within that collection by using Team ⇒ Team Project Collection Settings ⇒ Source Control and selecting the Workspace Settings tab as shown in Figure 3.21. In addition the server administrator is able to enable asynchronous checkouts for Server workspaces where an explicit check-out operation is required. Checking the option enables Visual Studio to check out the file automatically in the background without blocking the user because enabling that feature disables features that may prevent that check-out from succeeding.

A user can convert his Local workspace to a Server workspace or vice-versa simply from the Manage Workspaces dialog by going to File ⇒ Source Control ⇒ Workspaces. Select the workspace and press Edit to get to the Edit Workspace dialog and press the >> Advanced button to see all the properties as shown in Figure 3.22.

To convert between a Local and a Server workspace, change the drop-down for the Location property.

Figure 3.21

There are other advanced options worth noting at this point. As introduced in Team Foundation Server 2010, a user can adjust the permissions on the workspace. Table 3.2 shows the different permission features available.

Table 3.2 Permission Features

Figure 3.22

Public workspaces make it easier for teams to collaborate when sharing a single machine. One specific example would be merging bug fixes into a mainline branch. By utilizing a public workspace, multiple team members can work together on a common machine to resolve merge conflicts, thereby making the merge process run faster and smoother.

A new setting in Team Foundation Server 2012, however, is the File Time setting. In previous versions of TFS the timestamp of the file in the local filesystem is the time at which that file was downloaded to the local machine (that is, the last time a get was performed on it that involved a modification to the file). If desired, you can set the File Time option to Check In, which means that the timestamp of the file in the local filesystem is that at which the file was originally checked in to Team Foundation Server. This makes it easier to work with certain legacy tools or build/deployment processes that rely on the file modification date to determine if an action should be performed on it.

Server Workspaces

In a Server Workspace, when a Get is performed to download the file to the local filesystem the server tracks which version of the file is on the local machine and the file is set to read-only. This way the server is aware of exactly which file versions you have locally. Consequently, when you tell the server you would like to Get Latest, the server can simply send you the latest versions of all the files that you don't have yet because it is aware of exactly what you have. When you want to edit the file you must perform an explicit check-out operation (however, this is frequently automated for you by the IDE integration in Visual Studio or Eclipse). If you are able to check out the file (that is, nobody has an exclusive lock of the file) then the file is set to read-write in the local filesystem, and you may perform edits.

Files are listed in your Pending Changes view the moment that they are checked out. For example, if you start to edit a file in Visual Studio, undo your changes, and save the file again then it is still shown with an edit pending. However, if you check in a file that has not been modified then the server removes it from the changeset before it is committed.

Because an explicit check-out operation is performed, the server can notify users (via the console window) if they are editing a file that another user has also checked out. This allows for early collaboration between developers when they discover they are working on the same file.

However, the user must inform the server about any operation they are performing to their local files. If the server is not aware that a local file has been modified or deleted (for example if that was done outside of Visual Studio) then it does not know to re-send that file when a Get Latest is performed. This is the most frequent source of the complaint with older versions of Team Foundation Server, that sometimes “get didn't get” when the user was expecting it to. The requirement to force a check-out before edit also made it harder for the user to work with tools outside of the source code management environment.

In addition, as the server needs to be informed explicitly before a file is edited, a Server workspace works best when there is a permanent online connection to the server. The offline behavior of server workspaces has been improved with each version of TFS and has been improved further still in the latest release. (For example, many of the tool windows now work asynchronously so that they do not lock up the user experience. If they suddenly find that they are waiting a long time for a server call to return when unknown to the UI, it is because the network connection to the server has been terminated.) However, server workspaces, by design, work best when an online connection is available so the experience for frequently disconnected users is not good.

Local Workspaces

With a Local workspace, the metadata about the versions of files in the workspace are stored in a hidden folder at the root of the workspace called $tf on Windows filesystems or .tf on Unix filesystems. This allows for edit, add, rename, delete, undo, and some compare operations to be carried out locally without any communication with a server. The $tf folder contains a copy of the last version of the file that was downloaded into the workspace along with some additional metadata. This allows for edits to be performed on the local filesystem without requiring an explicit check-out operation to the server, meaning that the files in the Local workspace can be read/write on Get.

Making the files read/write on Get dramatically reduces the friction when editing with other tools outside the source code management environment (such as Notepad on Windows or Xcode on the Mac). The lack of an explicit check-out operation also means that working offline is much improved.

Another advantage of Local workspaces is that as changes are detected by the disk scanner, it is easy to determine when you have deleted files on disk and so performing a get on those files allows them to be downloaded again. In addition, a file is only shown as pending edit (that is, checked out) when the contents of it are different than the last version downloaded from the server. Therefore, if you edit a file, save it, and then undo the changes and save it, the file does not show in the Pending Changes list as there are no changes to submit.

However, to enable all these great features, the workspace contents have to be scanned and compared with the last copy downloaded into the workspace. Therefore, the larger the number of files in the workspace, the slower this disk-scan operation can become. That said, modern computers and hard disks are very fast, and users with fewer than 100,000 files in their workspaces should not notice much of a slowdown. Even when they do, it is a linear reduction in performance. The number of files in the Local workspace before a slowdown becomes a problem is increased using faster 10K hard drives or is improved even more when using SSD devices and so on.

Because of the reduced friction to developers in using Local workspaces, they are the default option out the box with Team Foundation Server 2012. However, some organizations, especially those requiring a high degree of control, may value the features provided by Server workspaces, in which case the default can be defined as the default using the dialog shown in Figure 3.21.

Command-Line Tools

You can manipulate any part of the version control system using the Team Foundation command-line tool. The tool itself is called tf.exe (short for Team Foundation) and is installed with Visual Studio. For Unix-based systems (such as Mac OS X, Linux, Solaris, and so on) a cross-platform command-line client (simply tf) is available as part of Team Explorer Everywhere, which is a free download.

For example, to create a new workspace, simply type the following command:

> tf workspace -new MobileExplorerProject -collection:http://tfsServer:8080/tfs/
     YourProjectCollection

In the preceding example, a new workspace is created, called MobileExplorerProject. You can exercise a great deal of control over the version control system using the tool. For example, you can manipulate workspaces, add working folders, set permissions, view changesets, labels, and much more. The command-line tool has the most functionality available of all the version control clients for Team Foundation Server. Features are exposed via the command line that are not available from the user interface (UI) in Visual Studio or Eclipse.

You can also use the command-line tool to view the changes in your workspace by simply typing the following inside the workspace:

> tf status 

To view a list of all possible commands using the command-line tool, run the following command:

> tf help

To get more help on a particular command, such as checkin simply type:

> tf help checkin

This provides a list of all options, along with some additional help information. You can also refer to the MSDN online documentation for more information.

Summary

In this chapter, you examined the core features of Team Foundation version control and how to use it for day-to-day development.

You found out how to use the Source Control Explorer and how to check in code, showing you the concepts of workspaces, changesets, and shelvesets. You learned how to view the history of files and apply labels. The chapter also covered advanced concepts, such as workspaces and the differences between Local and Server workspaces.

Version control is the most important tool you can use to help you manage your development process by providing an effective way of organizing your source code. In Chapter 4, you learn some branching and merging, some best practices, and how to configure Team Foundation Server to implement those strategies. Part IV of this book talks more about software development in general and provides guidance about how to make sure the code that you are checking in is good code.