|
|
Rank: Administration
Groups: Administration
, Member
Joined: 5/8/2009
Posts: 1,576
Points: 5,631
|
The source control system that ships as a part of Visual Studio Team System(VSTS) and Team Foundation Server is a brand-new system from Microsoft; it is not an enhanced version of Microsoft’s previous source control system, Visual Source Safe. Team Foundation Source Control (TFSC) was built from the ground up to be an enterprise-class system capable of handling hundreds or
even thousands of concurrent users.
Because the Team Foundation source control system is merely another service provided by TFS, it rides on top of the same three-tier architecture. It relies on SQL Server as the database to house the source control repository, exposes access to the repository through a set of services hosted on a TFS application tier server, and leverages Visual Studio as the client. The following figure shows a diagram depicting this system architecture.
Armed with this basic understanding of the Team Foundation source control system, you’re ready to look at the tooling integrated into Visual Studio that allows VS users to perform basic and advanced source control tasks.
|
|
|
|
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 5/8/2009
Posts: 1,576
Points: 5,631
|
Connect To Team Foundation Source Control
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. 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.
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 5/8/2009
Posts: 1,576
Points: 5,631
|
Branching a Code Line
Branching is a feature that allows a collection of files to evolve in two or more divergent paths. Branching is frequently used when teams have to maintain two or more similar code bases, as can occur when a product is released and work must begin on the next version.
Branching in Team Foundation source control is analogous to a file system copy operation. Branching will preserve the history of the folders and files that you are branching and will allow changes to be merged from the old files to the new ones. Branching can be conducted through Source Control Explorer.
A branch operation has a source and a target. The source provides the name and version of the file or folder being branched and the target provides the location of the destination file or folder. If the specified target is the name of a folder that exists in the server, the actual target will be created within that folder; otherwise, the actual target is as specified.
To branch a code line:
- On the View menu, click Other Windows, and then click Source Control Explorer.
- In Source Control Explorer, locate the folder or file that you want to branch, right-click, and click Branch.
- In the Branch dialog box, in the Target text box, modify the location and name for the new branch. You may also click Browse… to move to a location.
- In the Branch from version section, in the By list box, click the version of the source from which you want to create your new branch.
- As an option, select the Create local working copies for the new branch option that creates copies of the source on the local workspace. Leave the check box unchecked if you do not need a local copy. Also, leaving the check box unchecked prevents a large selection of items from being downloaded to your computer. This will improve your computer's performance.
- Click OK. the new branch is created and presented in Source Control Explorer.
- As an option, if you select the Create local working copies for the new branch option, and the local folder you selected is not mapped in the current workspace, the system displays a Browse For Folder window.
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 5/8/2009
Posts: 1,576
Points: 5,631
|
Creating a Workspace
Before you can perform Team Foundation source control commands on your computer, you must have a workspace. A workspace is a local copy of the files and folders in the server. When you add, edit, delete, move, rename, or otherwise change any source-controlled item, your changes are isolated in your workspace where you can safely build and test your changes. It is only when you perform a check-in operation that these changes are committed to the server and available outside of your workspace.
The following procedures demonstrate creating a workspace from Visual Studio Team Foundation Server.
- From the File menu, select Source Control, and then click Workspaces.
- In the Manage Workspaces dialog box, click Add.
- Type a descriptive name in the Name box, enter a comment describing the new workspace in the Comment box, and provide alternative Owner and Computer name values, as necessary.
- Under Working Folders, in the Source Control Folder box, click the text box and then the ellipsis (…).
- In the Browse for Folder dialog box, select a server folder, and then click OK.
- Under Working Folders, in the Local Folder box, click the text box, and then click the ellipsis (…).
- In the Browse for Folder dialog box, select a folder on your computer, and then click OK.
- In the Add Workspace dialog box, click OK to create the workspace.
- In the Manage Workspaces dialog box, click Close.
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 5/8/2009
Posts: 1,576
Points: 5,631
|
Getting Files from Source Control Server
With the workspace established, you can now view the workspace using the Source Control Explorer. To open it, on the View menu, select Other Windows and then select Source Control Explorer.
Every workspace will initially be empty. If a file exists on the server but not locally, its filename will be grayed out, indicating that these are server-only copies at this point. To actually populate the local workspace with the files from the Team Foundation source repository, you need to execute a Get Latest command.
- In Source Control Explorer, click Workspace on the toolbar, and select the new workspace from the list.
- With the new workspace selected, items that appear dimmed indicate that they have not been copied to your local workspace. Go to a folder or file that you want to add to the new workspace, right-click, and click either Get Latest Version to copy the latest version of the items, or Get Specific Version. If you click Get Specific Version, the Get dialog box appears.
- In the Get dialog box, make sure that the file or folder you want to get is selected and then select what type of version you want to get from the Type drop-down list:
- Changeset Get a version based on a changeset.
- Date Get a version based on a date. If selected, click a date in the Date list.
- Label Get a version based on a label.
- Latest Version If selected, updates with the latest version on the Team Foundation source control server.
- Workspace Version Gets a version based on the workspace.
- (Optional) Click the Overwrite writable files that are not checked out option. If selected, files from the server will overwrite all files that do not have the read-only attribute associated with them and are not checked out. Only files on the server, which are different, will overwrite the files in the local workspace. By default, this option is not selected.
- (Optional) Click the Force get of file versions already in workspace option. By default, this option is not selected.
- Click Get. Source Control Explorer is displayed. If you clicked Latest Version in step 5, the Latest column is updated with the status of Yes.
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 5/8/2009
Posts: 1,576
Points: 5,631
|
Customizing Check-in Policies and Notes
Project teams have different rules that users need to follow in determining whether a check-in is appropriate. For instance, checking in a class file that doesn’t compile probably isn’t a good idea. Anyone else performing a Get Latest operation or Check Out on the file would have his or her project “broken” because of your changes. Team Foundation Source Control recognizes the importance of vetting check-ins and provides a way to enforce certain rules on check-in through the use of check-in policies.
The check-in policies are available in TFS are listed in the following table.
| Policy Type |
Description |
| Builds |
This policy requires that any code changes have been compiled and the last build was successful. |
| Work Items |
This policy requires that one or more work items be associated with every check-in. |
| Changeset Comments Policy |
Reminds users to add meaningful comments to their check-ins. |
| Code Analysis |
This policy requires that Code Analysis is run with a defined set of rules before check-in. |
| Testing Policy |
Ensures that tests from specific test lists are successfully executed before checking in. |
Check-in policies are typically set up and configured on a per-project basis by project administrators; a default set of selected policies is usually turned on by the TFS process template currently in use. To configure which policies are in effect for your current project, you would access the Team Foundation Server source control settings available by selecting Team -> Team Project Settings -> Source Control Settings. The Source Control Settings window has a Check-in Policy tab, which allows you to select the specific policies to be enforced for the current project.
-
From Team Explorer, right-click your team project, choose Team Project Settings, and then choose Source Control.
The Source Control Settings dialog box appears.
-
Click the Check-in Policy tab and then click Add.
The Add Check-in Policy dialog box appears.
-
In the list box under Check-in Policy, select the desired policy type, Code Analysis, Testing Policy or Work Items, and click OK.
If you selected Code Analysis, the Code Analysis Policy Editor appears.
-
Click all the rules you want to specify, and then click OK.
If you selected Testing Policy, the Testing Policy dialog box appears.
-
Click Browse to specify a metadata file, select the test desired, and then click OK.
If you selected Work Items, the Work Items policy type is added to the Source Control Settings dialog box.
-
When you are satisfied with the settings for the check-in policies, click OK.
The new check-in policy now displays with future check-ins.
Creating Check-in Notes
Check-in notes are short pieces of text you can attach to the check-in items during the check-in process. Check-in notes become a part of the file’s historical metadata, are stored in the source repository, and can be viewed later so that you can get a sense for an item’s change history.
A check-in note consists of a category name or prompt and the actual note text. By default, there are three note categories:
- security reviewer
- code reviewer
- performance reviewer.
When performing a check-in, you can click on the Check-in Notes channel button to enter notes.
To further customize check-ins, you can define check-in policies that evaluate compliance of changes with organizational standards.
-
From Team Explorer, right-click your team project, choose Team Project Settings, and then choose Source Control.
The Source Control Settings dialog box appears.
-
Click the Check-in Policy tab and then click Add.
The Add Check-in Policy dialog box appears.
-
In the list box under Check-in Policy, select the desired policy type, Code Analysis, Testing Policy or Work Items, and click OK.
If you selected Code Analysis, the Code Analysis Policy Editor appears.
-
Click all the rules you want to specify, and then click OK.
If you selected Testing Policy, the Testing Policy dialog box appears.
-
Click Browse to specify a metadata file, select the test desired, and then click OK.
If you selected Work Items, the Work Items policy type is added to the Source Control Settings dialog box.
-
When you are satisfied with the settings for the check-in policies, click OK.
The new check-in policy now displays with future check-ins.
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 5/8/2009
Posts: 1,576
Points: 5,631
|
Bundling and checking in the related changes in a changeset
You can certainly checking out a file, making changes, and then checking that file back in. But in reality, it is recommended that you should bundle and check in the related changes in a changeset. A changeset is a logical container in which Team Foundation stores everything related to a single check in operation: file and folder revisions, links to related work items, check in notes, a comment, policy compliance and system metadata such as owner name and date/time of check in.
For example, you may check out three different files to fix a bug. When you perform a check-in, you will check in all three of these files at the same time and associate their check-in with the bug work item. This is where the changeset concept comes into play: The changeset bundles these three files into a single entity. In other words, the bug is, rightly, associated with the three files as a whole. It is associated with the changeset. Any related work items, notes, and metadata about the code change (date, time, user) are all associated with the changeset as a whole, and not to the individual files.
|
|
|
Guest |