Define the initial configuration of Team Foundation version control
Updated: July 15, 2016
By using the plug-in for version control, you can configure a team project's initial security permissions, check-out policies, and check-in notes.
In the XML file, you specify one or more tasks and their dependencies. Generally, you need only one task to configure settings for version control. For an example of a task that specifies these settings, see the VersionControl.xml file that is defined for a process template for Microsoft Solutions Framework (MSF).
The following table summarizes the names of the file, the folder, and the plug-in for the process templates for MSF.
You can change the name of the XML file and the folder name but not the name of the plug-in. Team Foundation Server does not include a mechanism for the deployment of client-side plug-ins, policies, or other modifications. If you want to deploy this kind of functionality, you must use your own distribution and installation program.
You can control whether multiple people can check out a file at the same time by specifying the exclusive_checkout element.
If the required attribute is set to true, only one person can check out a file at a time. If this attribute set to false, multiple people can check out a file at the same time, and they must reconcile changes when they check in the file.
The following example shows how to require exclusive check-out:
You use the get_latest_on_checkout element to configure the default behavior when a user checks out a file for a team project.
If the required attribute is set to true, the most recent version of an item, or tip, is downloaded every time that a user checks it out. This behavior resembles the check-out behavior in Visual SourceSafe.
If the required attribute is set to false, the check-out operation will check out the local version in your workspace. By default, this attribute is set to false.
The following example shows how to specify that the default check-out behavior is to get the most recent version of an item when a user checks it out.
The developer provides check-in notes when he or she checks in code. These notes describe whether the code changes are related to team processes and, if they are, how. For example, a check-in note can indicate whether the change was made because of a security review, and the note can include details about the changes relative to the security review.
You use the following syntax for a checkin_note element
<checkin_note label="" required="" order=""/>
The following table describes the attributes of the checkin_note element.
The label that describes the check-in note. The label appears in the Pending Check-ins dialog box when a user checks in a change.
Specifies whether the check-in note is required to have a value. If this attribute is set to true, the check-in note must have a value. If this attribute is set to false, a value is optional.
Specifies an ordinal number to indicate in what order to display the check-in notes. This attribute is optional.
The following example shows how to customize the check-in notes for MSF for Agile Software Development to create an additional check-in note that is named "Documentation Impact" and that is not required to have a value.
<taskXml> <checkin_note label="Code Reviewer" required="false" order="1"/> <checkin_note label="Security Reviewer" required="false" order="2"/> <checkin_note label="Performance Reviewer" required="false" order="3"/> <checkin_note label="Documentation Impact" required="false"/> </taskXml>
Version control has a specific set of permissions that you can configure for a process template. By specifying permissions, you define what actions security groups and individuals can perform on items that are under version control. For more information, see Control access to functional areas.