26.04.2015 Views

Team Development with Visual Studio Team Foundation Server

Team Development with Visual Studio Team Foundation Server

Team Development with Visual Studio Team Foundation Server

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

from, you can use the TFS Migration and Synchronization Toolkit, available at<br />

http://www.codeplex.com/MigrationSyncToolkit, to write your own migration tool.<br />

Microsoft is currently working on a ClearCase converter. When this converter is ready, it<br />

will be announced on the TFS Migration blog at http://blogs.msdn.com/tfs_migration<br />

Component Software has created a converter that is compatible <strong>with</strong> GNU RCS, CS-<br />

RCS, GNU CVS, Subversion (SVN), and <strong>Visual</strong> SourceSafe (VSS).<br />

Additional Resources<br />

• For more information about TFS migration, see the “TFS Migration blog” on the<br />

MSDN Web site at http://blogs.msdn.com/tfs_migration<br />

• To download the TFS Migration and Synchronization Toolkit from CodePlex, go to<br />

http://www.codeplex.com/MigrationSyncToolkit<br />

• For more information about the Component Software converter, see<br />

http://www.componentsoftware.com/Products/Converter/<br />

Project / Workspace Management<br />

• Isolate a single developer using workspaces rather than branches.<br />

• Delete and rename files by using source control, not Windows Explorer.<br />

• Only delete and rename <strong>with</strong> your solution open.<br />

• Create one team project per application if you want to move your assets between<br />

application versions.<br />

• Create one team project per version if you want to start fresh <strong>with</strong> each<br />

application version.<br />

• Use branching to share code and binaries that require integration testing.<br />

• Avoid workspace mapping to support cross-project dependencies.<br />

• Create workspace mappings at the team project root level.<br />

• Use a unique local folder path on shared computers.<br />

• Consider mapping only part of the source tree.<br />

• Structure your source tree to support branching.<br />

Isolate a Single Developer Using Workspaces Rather Than Branches<br />

To isolate your work from the rest of your team, use an additional workspace and do not<br />

create a new branch. Use your primary workspace to contain references to the files and<br />

folders being worked on by the rest of the team (that is, containing the shared source) and<br />

create a second workspace to maintain the files and folders that you want to isolate. You<br />

might want to isolate these files in order to evolve specific files in parallel <strong>with</strong> work that<br />

is happening elsewhere. For instance, this can be used to work on risky pending changes,<br />

or experimental changes. By using a second workspace, you reduce additional branch and<br />

merge complexity.<br />

To create a secondary workspace

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!