TEAM FOUNDATION VERSION CONTROL AN OVERVIEW AND WALKTHROUGH By: Michael Mallar

What is Version Control? Version Control: is the management of changes to documents, computer programs, and other groups of information. The changes made are called revisions, and each revision is associated with both a timestamp and name of the editor. In computer software engineering, revision control: 1.Provides control over changes to source code. 2.Allows for the development of two versions of the software concurrently. Issues mainly arise from the maintaining multiple identical copies of the program The steps taken in version control include: 1. Checking out the data from a repository 2. Editing the data as a working copy 3. Checking in where the working copy is checked before it finally is accepted back into the repository as a new version.

The Structure of Version Control Version control is typically integrated with a single authoritative data collection. The repository, check-out, and check-in steps are all authorized with reference to the central repository. In distributed revision control, data can be checked out and checked in at any repository. Sometimes the checking in of data at different repositories leads to a merger or patch in the data

Management Models Atomic operations: When the system is left in a consistent state even if it is interrupted. A commit operation is usually the most critical because it tells the revision control system to make changes both final, and available to all users. File locking: Involves locking files so that only one developer at a time has write access to the central repository copies. Once one developer checks out a file, others may read that file, but no one else may change it until that developer checks in the updated version. Version merging: Typically only possible if the data structure is simple. The second developer that is checking in will need to make sure that the changes are compatible and check that the merge does not introduce logic errors within the files.

Team Foundation Server Overview Team Foundation Server is a Microsoft product which provides: 1.Source code management 2.Reporting 3.Requirements management 4.Project management 5.Automated builds 6.Lab management 7.Testing and, release management capabilities * Can be used as a back end to numerous IDE’s but, is tailored for Microsoft Visual Studio and Eclipse.

Team Foundation Version Control TFVC is a centralized version control system allowing teams to store any datatype within its repository. It supports two different types of workspaces: 1.Server Workspaces: Allow developers to lock files for check-out, and provide notification to other developers that files are being edited. 2.Local Workspaces: Designed so that files are not read-only and they do not have to be checked out before working on them. All conflicts are dealt with at check-in. Supports a number of configurable rules for developers, called Check-in Policies. Supports a Code Analysis feature that is known as FxCop, where an analysis can run against code checked into the server.

TFVC Walkthrough This walkthrough demonstrates version control features in Visual Studio Team System Team Foundation Server. This walkthrough describes: 1.Set Team Foundation version control as your default version control plug-in 2.Create a new project. 3.Add the project to version control and create a local workspace: storing, editing, and testing version-controlled files. 4. Checking in a solution. 5. Adding a file to the version-controlled project and editing an existing one. 6. Commit all pending changes in the local workspace to the version control server.

Setting TFVC as Plug-in To configure Visual Studio to use Team Foundation version control: 1.On the Tools menu, select Options. 2.In the Options dialog box, locate Source Control, 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.

Adding a Project Adding newly created projects Team Foundation version control creates individual workspaces for your team. A workspace provides an isolated space where you can write and test your code without affecting the checked-in sources. A workspace also allows you to be unaffected by changes made by teammates. A workspace is a copy of the files and folders stored on the Team Foundation Server. On the TFS, when you manage any version-controlled item, your changes are on the copy, and is tracked as a pending change.

Adding a Project (Continued) To create a new solution and project: On the File menu, click New, and then click Project.

Adding a Project (Continued) 1.In the New Project dialog box, select a Template in the Project Types pane. 2.In the right pane, click an Application type. 3.In the Name box, type a name, and then type a path in the Location box. 4.Select the Add to Source Control box, and then click OK.

Adding a Project (Continued) 5. In the Add Solution to Source Control box, select the team project that you want to use for this walkthrough. 6. Click OK.

Checking Pending Changes - The Pending Changes window provides information about the status of pending changes in your workspace, which can be used to keep track of information associated with your changes. To check in pending changes for the solution to version control: 1. If the Pending Changes window is not open, on the View menu, click Other Windows and then click Pending Changes.

Checking Pending Changes (Continued) 2. The Pending Changes window will list your solution files. 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, you can enter a comment in the Comment box. 4. Click Check In to check in the pending add changes to the server.

Editing a Project When you add a file to a version-controlled project, Visual Studio automatically updates the project file. Newly added files are not checked in automatically, but are treated as pending additions to version control. A new change-set is created in the server when you check in.

Editing a Project (Continued) To add a file to a version- controlled project: 1. Right-click the project in Solution Explorer, click Add, and then click Class.

Editing a Project (Continued) 2. In the Add New Item dialog box, click Add to add “xxxx“.cs to your project. In Solution Explorer, the project's signal icon is changed from a blue lock to a red check mark, indicating that the project file is checked out. *Note that a plus (+) symbol appears indicating a pending addition.

Workspace Version Syncing The “Get Latest” operation keeps files in your workspace synchronized with the latest server version. By always synchronizing and building before checking in, you can avoid breaking the integration build. Breaking the build is when you and another user check incompatible changes, that results in preventing your application from compiling.

Version Syncing (Continued) 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).

Checking in Changes to the Server Checking in your changes to Team Foundation version control makes the project visible to your teammates. The Pending Changes window assumes that you want to check in all changes, but can easily excuse individual pending changes from being checked in When you select a file container such as a project or solution, you are checking in that item and the items it contains. Individual team members can: - Create work items to track product defects or feature requests. - Associate a work item with a specific project. - Associate a complete work item with the source changes by marking it on the “Work-Items” channel in the “Pending Changes” window. - Add meaningful notes to each check-in.

Checking in Changes to the Server (Continued) You can check in pending changes in the following ways: 1.Right-click a checked-out file in Solution Explorer or Source Control Explorer. 2. Click Check In in the Pending Changes window.

How Check-In Works When you click Check In, the system bundles together the selected source files with any check-in notes and work items that have been specified. The bundle is uploaded to Team Foundation and is committed as a the new change-set. Work items in the change-set are updated to contain links back to the new change-set. They are then transitioned through a workflow based on predefined processing rules. The processing rules and workflow are created by the process template from the team project. notifications are generated to all team members who want check-in notifications.

Thank You! Questions?

Website References workspaces-vs-local-workspaces.aspxhttp://blogs.msdn.com/b/phkelley/archive/2013/05/29/server- workspaces-vs-local-workspaces.aspx 4.