Working with Team Foundation source control
Microsoft Team Foundation source control provides source-code version control functionality, which can scale to handle thousands of developers.
What is source control?
Source control is a system that helps manage source files that are shared by a team. By using source control, many people can work on the same set of files while minimizing the risk that one person might inadvertently delete the changes that someone else made to a file.
How does source control work?
Source files are stored in a source control system repository (Team Foundation server). Team members check files out to local folders on their computers, make changes to the files, and check them back in.
When a file is checked back in to the repository, the source control system makes a record of the change between the new version and the previous version. When checking in a file, the team member adds a notation to the file's record in the repository so that others can see what changes he or she made to the file. That way, if someone makes an unwanted change to a file, you can revert the file to an earlier state.
A file can be checked out by more than one person at a time. If a file is changed by someone else after you check it out, when you check it back in, the file will go through a merging process in which you will have to resolve any conflicts.
Team Foundation support in Blend
Team Foundation source control is integrated into Blend for Visual Studio 2012 so that you can do things such as viewing older versions of files, checking files in, adding files, and viewing file history, all in the Projects panel in Blend.
You enable source control functionality in Blend by setting up your computer to use Team Foundation source control, and then opening a solution that is bound. (If a solution or project is bound, it contains Team Foundation information and can use source control functionality from inside Microsoft Visual Studio and Blend.)
For more information, see the following topics:
From that point, you can right-click the solution, projects, or individual files in the Projects panel to perform source control tasks.
For more information, see the following topics:
Some more advanced source control tasks can be done only in Visual Studio Team System or Team Explorer, not in Blend, such as creating a new solution under source control, binding solutions and files, explicitly checking out files exclusively (so that no other team member can check them out at the same time), and configuring file merging options. To perform those tasks, you can use Visual Studio Team System 2010 Team Explorer or the full version of Visual Studio Team System 2010. For more information, see Using Team Explorer, Working with Team Foundation Version Control, and How to: Bind and Unbind Projects and Solutions on MSDN.
.gif "Suggerimento") Suggerimento |
|---|
If a solution under source control is not bound, you can still use Blend to modify the files in the solution, but you must use Microsoft Visual Studio Team System Team Explorer to check the files out and in. Because Team Explorer is a free download, this is a less expensive option than purchasing a copy of Visual Studio Team System to modify files under source control. You can open the same solution in Blend and Team Explorer at the same time. When you modify the source control status of files using Team Explorer, be sure to refresh the source control status of the files in Blend. For more information, see Refresh the status of files under source control. |
Source control best practices
Knowing how source control works and using the following straightforward guidelines can help team members efficiently work on a solution together:
Use a source control system.
Correctly using a source control system enhances cooperation, teamwork, and efficiency while minimizing the risk of losing work.
Obtain the correct permissions.
To use the source control features in Blend, you must have at least Contributor permissions on the Team Foundation server. For more information, see Team Foundation Server Permissions on MSDN.
Keep your source files in source control.
Keep a copy of each source file you need to build your solution in source control and make sure all solutions and projects are bound. Don't store files that are compiled or generated from source code in source control.
The following table lists examples of files that do and don't need to be kept in source control:
Add the following types of files to source control
Don't add the following types of files to source control
Solution (.sln) and project (.csproj, .vbproj) files.
Cached files (.cache, .suo).
Source files that your project builds (.xaml, .cs, .vb).
Files that get built by your project in \bin or \obj folders.
Media files (.jpg, .wav, .wmv, and so on).
Files or projects that are used to generate media files (Microsoft Expression Design files, though these can be kept under source control).
New projects that you create in a solution or new files that you create in a project.
Projects that exist outside the solution folder, or files that exist outside project folders. This can occur if you create a new file or project but save it outside the correct parent folder.
Assemblies (.dll files) that your solution depends on.
Projects that build the assemblies (.dll files) that your solution depends on, if the project exists outside your solution folder.
Keep all the files that you want under source control in your local Team Foundation workspace folder.
When you set up your computer to use Team Foundation source control, you create a local folder to which the Team Foundation server copies files. This is similar to creating a publicly-shared folder on your computer, but only the Team Foundation server has access to it. Anything that is under source control must be in that workspace; otherwise, the Team Foundation server will not be able to see it, which can cause errors like "Unable to determine workspace."
Keep all the projects and files that belong to a solution inside the solution folder.
If you create a new project in a solution, make sure that the project folder is created inside the solution folder. Blend will do this by default unless you change the Location field in the Add New Project dialog box.
For more information, see Add a project to a solution under source control.
If you add an existing project to a solution, make sure that you copy the project folder to the solution folder first. Otherwise, you will not be able to add the new project or its files to source control.
For more information, see Add files and folders to a project under source control.
You can link to projects and items outside the solution folder; however, make sure that these items are available when you build your project. This might require using Team Explorer to get copies of the files from the Team Foundation server. For more information, see How to: Get the Source for Your Team Project on MSDN.
Make sure that you are working on the latest version of a file.
Follow the file check-out procedures that your source-control administrator has specified. For example, your team might require you to get the latest version of all files before checking files out, or to check files out explicitly before working on them (instead of checking out a file implicitly by saving it [Ctrl+S] in Blend).
For more information, see Get the latest copies of project files.
As other people on your team make changes to files in your project source control repository, the copies of those files that you have in your workspace grow "stale"—they no longer include all the changes that your team has made. Checking in a stale version of a file and replacing somebody else's newer version creates extra work and increases the risk that you will lose some important modifications to the file.
For more information, see Merge and resolve conflicts when checking files in.
Check out only what you need.
Check out only the files that you plan to modify. Don't check out an entire folder unless you plan to modify every file in that folder.
Check in promptly.
Don't leave your files checked out any longer than necessary. Check your files in as soon as you are done modifying and testing them. By doing this, you make sure that your teammates have access to the latest versions of the files.
For more information, see Check files in and out.
Write good check-in comments.
When something goes wrong, you can use good check-in comments to help identify where it went wrong and how to fix it more quickly. Even if nothing goes wrong, you'll be able to easily see what changes you made and why you made them by viewing the history of a file.
For more information, see View or compare the changes made to files.