Create a TFS Environment

You can use Microsoft Team Foundation Server (TFS) as a version control provider for Enterprise Architect. The first step in doing this is for a TFS administrator to install and configure the TFS server and client applications. A number of basic tasks are performed in creating an operational TFS environment.

Tasks in Creating a TFS Environment



See also

Obtain and install TFS

Enterprise Architect uses the TFS command line client to integrate TFS version control.

The TFS command line client is normally available as part of your Visual Studio installation.



Choose a TFS project

It is good practice to create a new TFS project, or least a new Source Control Folder within a project, for each Enterprise Architect project being added to version control with TFS.

If you have a single Enterprise Architect project that contains many different models (for example, a DBMS hosted project with multiple model root nodes), you might choose to create a new TFS project for each separate model.

For further information, please consult your TFS product documentation.



Create a TFS workspace

A working copy folder must exist on each users' machine, for Enterprise Architect to use when exporting and importing the version controlled Package files. It is this folder that is specified as the Local Project Path, when defining your Version Control Configurations.

The working copy folder is the 'sandbox' where you modify the controlled files. The working copy folder is usually associated with a folder that exists within the version control repository.  In TFS, the TFS workspace is used to map a local working folder on your PC to a Source Control Folder within a TFS project.

TFS 2012 and VS 2012 (and later versions) feature a new type of workspace called 'local' workspaces.  Do not attempt to use TFS 'local' workspaces with Enterprise Architect. You must use only 'server' workspaces for Enterprise Architect version control, as 'local' workspaces do not support the application of checkout locks to files.  Enterprise Architect relies on the presence of checkout locks to ensure that Packages can only be checked out exclusively and that a given Package is not already checked-out in some other project (for instance, in a Private Model deployment).   This is necessary because it is not practical to merge the XMI Package files that Enterprise Architect uses for version control.

A single TFS workspace can map many different local folders, each one to a separate Source Control Folder. In this case, TFS can take a long time to work through and update the files in all of those folders, and the system might appear to 'freeze' whilst it waits for TFS to hand back program control.

You can avoid this if you keep your version controlled Package files in a folder that is separate from other artifacts, such as source code files, creating a separate work space to use just for your Package files, or creating and mapping a separate folder for Package files within an existing workspace.


TFS Workspaces

Configure exclusive check-outs

The XMI format files used for the version control of Enterprise Architect's Packages can not be merged like ordinary text files. Therefore, Enterprise Architect must enforce serialized editing of its version controlled Packages.  As a consequence, it is important that TFS is configured to use 'exclusive checkouts' for XML files.


TFS Exclusive Check Outs


·TFS can also be used with an SCC client; the MS TFS-SCC client is available for download from Microsoft's web site
·MDG Integration for Visual Studio 2005 or 2008 enhances TFS support by providing access to, for example, work items and bugs within both Enterprise Architect and the MDG Integration product

Learn more