TFS Source Control Resources

Source of information:

• http://www.infoq.com/articles/agile-version-control
• TFS Installation Guide
• TFS Branching Guideline
• MSDN Journal February 2011 Branching and Merging Guidance

Team Foundation Server Permissions

---

You can control access to the team projects and team project collections in your deployment of Visual Studio Team Foundation Server by understanding and configuring the permissions that are assigned to the users and groups in that deployment. 

Permissions determine the authorization for user actions such as workspace administration and project creation. When you create a project in Team Foundation Server, four default groups are created for that project regardless of your choice of process template. By default, each of these groups has a set of permissions that are defined for them and that govern what members of those groups are authorized to do.

• Project Administrators
• Contributors
• Readers
• Builders

In addition to the default groups that are created for each team project, when you create a team project collection, seven default groups are created for that collection regardless of your choice of process template. Each of those groups also has a set of permissions that are defined for them.

• Project Collection Administrators
• Project Collection Service Accounts
• Project Collection Build Administrators
• Project Collection Build Service Accounts
• Project Collection Valid Users
• Collection Proxy Service Accounts
• Project Collection Test Service Accounts

Five default groups are created at the server level when you install Team Foundation Server. Each of these groups has a set of permissions that are defined for them.

• Team Foundation Administrators
• Team Foundation Service Accounts
• Team Foundation Valid Users
• SharePoint Web Application Services
• Work Item Only View Users

To effectively manage user membership in these default groups and to create custom groups, administrators must first understand the meaning of the permissions and the security implications for explicitly setting permissions.

Permission Settings

---

You can specify two explicit authorization settings for permissions in Team Foundation Server: Deny and Allow. There is also an implicit authorization that neither sets the permission to Allow nor sets the permission to Deny. This authorization is an implicit Deny setting that is referred to as Unset.

Deny

Deny denies authorization for the user or group to perform the actions that are stated in the permission description. Deny is the most powerful permission setting in Team Foundation Server. If a user belongs to a Team Foundation Server group that has a specific permission set to Deny, that user cannot perform that function, even if he or she belongs to another group that has that permission set to Allow. The only exception to this rule occurs when the user is a member of either theProject Administrators group for a project, the Project Collection Administrators group for a team project collection, or the Team Foundation Administrators group. If a user is a member of the Project Administrators group for a project, the permissions of that group override an explicit Deny for that user in a project. Similarly, if a user is a member of the Project Collection Administrators group, the permissions of that group override an explicit Deny for that user in that collection. If a user is a member of the Team Foundation Administrators group, the permissions of that group override an explicit Deny for that user in Team Foundation Server.

Allow

Allow grants authorization for the user or group to perform the actions that are stated in the permission description. Allow is the second-most powerful permission setting in Team Foundation Server and is set most frequently. If you do not explicitly set a permission to Allow, a user or group cannot perform that action in Team Foundation Server.

Unset

By default, most permissions in Team Foundation Server are not set to either Deny or Allow. The permissions are left unset, which implicitly denies both users and groups authorization to perform the actions that are specified in the permission description. However, because the permission is neither explicitly set to Deny nor explicitly set to Allow, authorization for that permission can be inherited from other groups of which the user or group is a member.

Default Groups and Permissions

---

Whenever you create a project in Team Foundation Server, groups are created at the project level. By default, each of those groups has certain permissions assigned to them. You can add permissions to these default groups, in addition to any groups or users whom you want to add at the server, collection, or project level.

Server-Level Groups and Permissions

By default, the following groups exist at the server level when you install Team Foundation Server:

• Server \Team Foundation Administrators   Members of this group can perform all operations for Team Foundation Server. This group should be restricted to the smallest possible number of users who need total administrative control over Team Foundation Server. By default, this group contains the Local Administrators group (BUILTIN\Administrators) for any server that hosts the application services for Team Foundation. This group also contains the members of theServer\Service Accounts group.
• Server \Team Foundation Valid Users   Members of this group have access to Team Foundation Server. This group automatically contains all users and groups that have been added anywhere within Team Foundation Server. You cannot modify the membership of this group.

• Server \Service Accounts   Members of this group have service-level permissions for Team Foundation Server. By default, this group contains the service account that was supplied during installation. This group should contain only service accounts and not user accounts or groups that contain user accounts. By default, this group is a member of Team Foundation Administrators.
• Server \Work Item Only View Users   Members of this group are restricted from using the full range of features that are provided when users view projects and collections in Team Web Access. Membership in this group is appropriate for those users who do not have a client access license for your deployment of Team Foundation Server.
• Server \SharePoint Web Application Services    Members of this group have service-level permissions for the SharePoint Web applications that are configured for use with Team Foundation Server, in addition to some service-level permissions for Team Foundation Server. This group should contain only service accounts and not user accounts or groups that contain user accounts. Unlike the Service Accounts group, this group is not a member of Team Foundation Administrators.
  
  
  
  
  
  
  
  
  Rolling Back a ChangeSet
  Using the Visual Studio command line prompt you can rollback a changeset or range of changesets from TFS
  
  
  Rollback command
  
  
  
  Thanks to Jamie Bate for this information.