Key Teamprise and Team System Concepts

The following terms are ordered from general to specific. If you wish to find a particular term use your browser's find command. For a detailed discussion of these concepts, and others, see the appropriate section of the Teamprise Explorer User Guide.

If a term you are looking for does not appear on this list, you can find a more comprehensive list of Microsoft Team System terms in the Glossary for Team System located at the MSDN.

Term	Brief Explanation
TFS workspace	A TFS workspace is a location on a Team Foundation Server (TFS) where a record of changes between local files and corresponding repository files are stored. It can also be thought of as: a copy of the client side directory. a staging ground where local changes are persisted until they are checked in to the server. a collection of working folder mappings which can be viewed and edited in the Edit Workspaces dialog. Typically you synchronize your TFS workspace with the TFS repository as often as possible to ensure you (and others on your team) are working off the latest version. You synchronize your workspace with the TFS repository by issuing a Get Latest action. For more information on TFS Workspaces see the User Guide section: Managing TFS Workspaces with Teamprise and Understanding Check-in and Check-out Concepts.
TFS (Team) project	Team projects comprise all the effort of a software development project, including project management documents, work item tracking, and the source control repository. Directories you see in the Source control view are directories in the source control repository node, one of four nodes comprising a Team project. For a full definition of a Team project, See MSDN Team Foundation Team Projects.
Mapping	In order for the TFS workspace to recognize changes to your local files, it needs to know which server files correspond to which local files. You establish this correspondence when you create a mapping in your TFS workspace. A mapping is a declaration, instructing the TFS workspace that *local folder A* corresponds to repository folder A. TFS allows multiple mappings in a single workspace, but there are restrictions. See Managing TFS Workspaces with Teamprise for more information about workspace conventions.
Working Folder	A Working Folder refers to the client side folder of a TFS workspace mapping. When a user checks a file out to edit, the file is made "writeable" in his local working folder. Modifications made to files in a working folder are tracked in a TFS workspace. When a file is checked in, the TFS workspace ensures that the corresponding file in the server folder is updated with the changes.
Source Control Repository	Source Control Repository refers to the location on the Team Foundation Server where files in source control are managed. The source control repository is one of four nodes comprising a Team project. When you issue a Get Latest operation, you are retrieving files from the source control repository.
Check In	Check In refers to the task of committing a pending change to a TFS repository. When you check in pending changes, a new changeset is created on the server. Your teammates can then access your code by issuing a Get Latest action. See also: Understanding Check-out and Check-in Concepts
Check In Policy	A Check In Policy is a client-side code module that is run by Teamprise during check-in, before the changes have been sent to the Team Foundation Server. The code inspects the changes about to be sent to the server and can prohibit the check-in if the changes do not comply with the business rules the policy implements.
Check Out	Check Out refers to the task of notifying the TFS server that you are changing the status of a resource from locked to writeable. When you check out for edit, TFS appends an edit to that resource. Checked out files are displayed in the Pending Changes view. See also: Understanding Check-out and Check-in Concepts
Console	When the Teamprise Console view is enabled it displays the output of Teamprise commands. If an error occurs during a Teamprise operation with TFS, the Console provides details that can help troubleshoot the cause of the error. The Teamprise Console opens by default when you perform an action. You can also invoke it from the Teamprise Explorer menu by selecting View > Console. See Reference section for Teamprise Console messages.
Source Control	(Also known as version control), Source Control is a central feature of the Team Foundation Server enabling team collaboration on software projects. Source Control is one of four nodes comprising a Team project. TFS enables the following source control tasks: Retrieve files from the source control server Check out files for modification Check in modified files Add files to the source control server Delete, rename, and move files from the source control server Compare files Resolve conflicts between files View history Compare versions Synchronize local and remote repositories
Lock Types	See Locking at Check-out and MSDN Understanding Lock Types
Check-in Notes	Check-in Notes are a way of collecting structured data about a check-in. A TFS administrator can make Check-in Notes mandatory and can customize them on a Team Project level.
Pending Change	When files are under TFS source control, changes in your TFS workspace are recorded locally, and only locally, until you check your changes in. These locally-persisting changes are referred to as a pending changes. The Teamprise Pending Changes \| Source Files view is used to view and manage pending changes. There are 2 categories of pending changes: File revisions are changes to the content of an existing file and are called "pending edits." Namespace changes are location-based changes and are called "pending additions", "pending deletions", "pending moves", and "pending renames". The following actions can be performed on pending changes from the Teamprise Team menu or pending changes window: Check In, Undo, and Shelve. Note: the Team Foundation shelve and unshelve actions will be available in a future release of Teamprise. See Pending Changes at MSDN.
Changeset	A record of changes. 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, comments, and other metadata such as owner name and date/time of check-in. When you check-in a set of pending changes, Team Foundation creates a new changeset in the source control server and assigns it a unique changeset number. Changeset numbers are always assigned sequentially, so for instance, changeset #3 chronologically precedes changeset #4. No two changesets can have the same date/time of check in. Because of this property, changesets also represent particular points in time for the state of the server. Changesets can be viewed in the History view which lists all the check-ins on a file from the point the file was first added to source control; this includes check-ins from other workspaces.
Change Type	The following change types are possible in TFS and may be viewed in Teamprise: add edit lock delete rename merge branch When you check a file into TFS source control you are committing one of the above pending changes.
Get Latest Get Specific	Get Latest refers to the task of retrieving the most recent version of a file from TFS source control to your local working folder. Get Specific refers to the task of retrieving a specific version of a file from TFS source control to your local working folder.
Label	A Label is a tag given to a specific version of a file or a set of files. A label is usually applied when a project milestone is reached. A Project Lead may apply a label when an important build is made, thus making it easier to retrieve the exact source code which corresponds to that build.
Shelve/Unshelve	Shelving is a way to save a set of pending changes without committing them to source control. A Shelveset is saved to a location on TFS and is available to other team members who wish to download a pending change set to their local workspace.
Cloaking	In TFS when you map a Team directory, you can choose to create a cloak mapping on one of more child nodes. When a child directory is cloaked (hidden), a Get Latest operation on the parent directory retrieves all files and folders except those you designate Cloaked (as opposed to Active). If you previously downloaded child folders and directories, the Get Latest action depopulates these from your workspace, thereby freeing up space on your computer.
Repository	A database tier of the Team Foundation Server. The remote location where source code files, work items, and reports are stored.
Pend Edit	Pend edit is the most common type of pending change. When you check out a file from the repository, TFS assigns an edit status to the file which is visible in the change type column of the Pending Changes window.
Synchronize	You synchronize your working folder with the TFS source control repository using the Teamprise Get Latest action. If conflicts exist between the working and remote folders you are prompted to resolve any conflicts using the Teamprise merge tool.
Views	A view is rendered in the Teamprise Explorer window to facilitate exchanges with the TFS. Teamprise implements the following views: Team Explorer Source Control Pending Changes Console Read more about Teamprise Explorer window and ways to access these views.
Branch	A Branch is a copy of a file or folder at a particular point in time for the purpose of creating a separate line of development.
Merge	Whether you wish to Merge individual files or entire branches, the Teamprise merge tool is used to integrate changes from one version of a file or folder into another in order to create a new version. The merge tool resolves conflicts during a Get operation (such as get latest and get specific, a check in operation.
Work Item / Work Item Repository	A Work Item is used to track a unit of work that must be performed as part of a development process. In Teamprise, developers can receive their work assignments from within the Pending Changes \| Work Items view or by way of the Team Explorerview. Work Items are one of four nodes comprising a Team project. The work item repository is a separate repository from the source control repository but links can be made across repositories. Work items can have three types of links: Related Link (a link between two work items, such as a task to a bug) Hyperlink (a general hyperlink, such as a url) External link (a link to something outside of the work item repository, such as a changeset in the source control repository) See MSDN Documentation for more information on the WIT: Work Item Tracking in Microsoft Visual Studio 2005 Team System Managing Team Foundation Work Items
Build Agent	A computer or a server on which Team Foundation Build is installed. Before you create a new build definition, you must designate a computer or a server as a build agent. You can use the Teamprise user interface to designate new build agents or to manage existing build agents.
Build Definition	Used to manage the conditions under which a a build we be performed. The build definition defines the name, description, working folder mappings, trigger and specifies default values for the Build Agent on which the build should be run and the drop location for the build results. The build process is controlled in an MSBuild project file in the build configuration directory.
Build Configuration	All the files required to describe the build process are stored in the build configuration directory. This normally consists of an MSBuild project file called TFSBuild.proj and an MSBuild response file called TFSBuild.rsp
MSBuild	Microsoft's build orchestration system. It is the build system for Microsoft and Visual Studio. Similiar in concept to Ant or make but is implemented in .NET. It is a process that parses extensible build scripts defined in an XML based file. For more information on MSBuild see the MSDN MSBuild Reference.
Ant	Apache Ant is a software tool for automating software build processes. It is similar to make and MSBuild, but is written in the Java language, requires the Java platform. Ant is best suited to building Java projects. Ant uses an XML based script to describe the build process, by default the XML file is named build.xml. Ant is an Apache project. It is open source software , and is released under the Apache Software License.