Shulou(Shulou.com)06/02 Report--

Today I'll show you the details of how to analyze the improvements in the workspace in TFS 2010. The content of the article is good. Now I would like to share it with you. Friends who feel in need can understand it. I hope it will be helpful to you. Let's read it along with the editor's ideas.

In TFS (Team Foundation Server) 2005 and TFS (Team Foundation Server) 2008, the version control workspace has the following restrictions.

1. The creation time set by the owner of the workspace cannot be changed (constant)

2. A workspace can only be used by its owner

When we mention "using" a workspace, it may mean any of the following:

Unshelve shelvesets that are shelved in the workspace

Make a "get" in a workspace

Suspend or cancel pending changes in a workspace

Check in or shelve from a workspace

Eliminate conflicts in a workspace

.

In TFS (Team Foundation Server) 2010, we removed these restrictions. It is not difficult to add the ability to change the owner of the workspace, but making the workspace available to people other than the owner requires us to make the workspace a completely secure object. We use new security services to make these changes and set four permissions for users in a workspace. These permissions are: Read, Use, CheckIn, and Administer Use permissions including operations related to changing the state of the workspace (its definition, local version, conflicts, or pending changes). Most of the operations you normally use are included in Use permissions. You can take a look at the "use" list listed above in this article.

We separate the check-in permissions, that is, CheckIn permissions. The reason is that in some shared workspace scenarios, only a certain user (such as the owner) can check in. A user needs Administer permission to change the mapping, name, owner, description, or the computer on which a workspace is located. The user needs this permission to delete the workspace from the system or to change the access control list for the workspace.

Read permission is also a permission, but it doesn't play a role. In theory, it includes looking at the status of an existing workspace, such as viewing a workspace's mapping, viewing a workspace's pending changes, and so on. In TFS (Team Foundation Server) and TFS (Team Foundation Server) 2008, any legitimate user can view these properties in any workspace, and TFS (Team Foundation Server) 2010 does not change this behavior.

Use the Edit Workspace dialog box to change the permissions of the workspace

TFS (Team Foundation Server) 2010 does not provide a complete UI for permissions to manipulate the workspace. Users can choose from three permission configurations; one permission configuration is actually a template for a workspace access control list. The default permission configuration is Private workspace. A private workspace has the same behavior as workspaces in TFS (Team Foundation Server) 2005 and TFS (Team Foundation Server) 2008: this workspace can only be used by its owners. The access control list for a private workspace has only one entry, which is to grant all permissions to the owner-for example, John Smith:

YOURDOMAIN\ johnsmith: Read, Use, CheckIn, Administer

The other two "permission configurations" we provide are "Public-limited" and "Public". These two "permission configurations" also grant all permissions to the owner. In addition, they grant additional permissions to any legitimate user. For the "public-limited" permission configuration, other users are granted Read and Use permissions on the workspace. For a fully public workspace, every legitimate user in the team project collection has the same permissions as the owner: Read, Use, CheckIn, Administer.

Use a public workspace in Visual Studio

We need to log in to the machine where the public workspace is located. After starting Visual Studio 2010 and connecting to the server where the public workspace is located, you can see the workspace in the drop-down combo box in the Source Control Explorer and Pending Changes tool windows.

Users of Visual Studio 2008 or earlier cannot see public workspaces that belong to other users. They can only see their own work area.

In this example, I set the shared workspace to "Public-limited". As you can see, because I lack Administer permissions on this workspace, I can only view the mapping, owner, description and permission configuration of this workspace. Some controls are read-only.

Use a public workspace from the command line (tf.exe)

Again, you need to log in to the machine where the public workspace is located. If you have launched the Visual Studio 2010 command prompt, you can cd the mapping path to the workspace. In my case, the path is D:\ Proj. You can see that I tried to run a command below, but I couldn't find the workspace. This is because the local workspace cache file is for each user, who is never aware of a problem with the workspace. There are two ways to solve this problem:

1. Start Visual Studio immediately, and then connect to the team project collection, which populates the local workspace cache.

2, run "tf workspaces" to manually populate the cache file, through the command to achieve.

I chose to run "tf workspaces". We can see that the workspace belonging to other users is displayed, which means that I can already access the public workspace. Now my "tf get" command is successful.

Magical ownership.

If user B shelves changes in user A's workspace, user B is the owner of the shelveset that was just created. Similarly, if user B checks in changes in user A's workspace, user B is marked as the user who submitted those changes.

There is no owner for a specific pending change-only the workspace has an owner, and if user A checks out the file.txt file in user B's workspace for editing, some UI components will indicate that the "file.txt" file has been opened by user B and is being edited, even though user An is the one who suspended the change. It also states more precisely that the "file.txt" file that is opened and edited in Workspace X belongs to user B.

Permission check failed

Error message "TF14091: you cannot perform this operation on workspace {0} because you are not the owner of the workspace" in TFS (Team Foundation Server) 2005Compact 2008. It no longer exists in TFS (Team Foundation Server) 2010. Instead, you will receive the following message indicating which workspace permissions are required for this operation:

TF204017: this operation cannot be completed because the user ({0}) does not have one or more permissions necessary to manipulate the workspace {2}.

In the following example, the workspace is switched to "Private" just before the command is executed.

AdminWorkspaces Global Authorization

From 2005 to 2010, all versions (Team Foundation Server) have a global license called "Administer Workspaces" or "AdminWorkspaces" for short. By default, this authorization is granted to the administrators of the team project collection. Even if they do not have Administer permissions, users with AdminWorkspaces authorization can automatically obtain Administer permissions on all workspaces of the system. This authorization allows administrators to remove outdated workspaces from the system and reclaim ownership of workspaces belonging to employees or contractors who no longer belong to the team during the holidays. Users with AdminWorkspaces authorization can create workspaces on behalf of other users.

Let's go back to the previous example, where some of the options in my Edit Workspace dialog are locked because the workspace is "Public-limited", and if I have AdminWorkspaces authorization, we can see that I now have full access to the dialog. My valid permissions are "Read, Use, Administer". If I want to have "CheckIn", I can grant this permission to myself by changing the permission configuration of the workspace to "Public".

Custom permissions

Although UI provides only three ready-made permission templates, this server supports customizing access control lists on the workspace. You can use security services and version control services to query the complete access control list. The GUID (Globally Unique Identifier: global unified identifier) of the workspace's security namespace is a well-known constant, and for any given workspace, the version control client object model has a tag in this namespace that can be accessed through the Workspace.SecurityToken attribute. The following code example shows how to extract and display an access control list for a workspace inferred from the current directory.

(this code sample needs to reference MS.TeamFoundation.Common assemblies, MS.TeamFoundation.Client assemblies, MS.TeamFoundation.VersionControl.Common, assemblies, and MS.TeamFoundation.VersionControl.Client assemblies. )

Using Microsoft.TeamFoundation

Using Microsoft.TeamFoundation.Common

Using Microsoft.TeamFoundation.Client

Using Microsoft.TeamFoundation.Framework.Common

Using Microsoft.TeamFoundation.Framework.Client

Using Microsoft.TeamFoundation.VersionControl.Common

Using Microsoft.TeamFoundation.VersionControl.Client

...

/ / Use the current directory to infer the workspace and TFS team project collection.

WorkspaceInfo wi = Workstation.Current.GetLocalWorkspaceInfo (Environment.CurrentDirectory)

TfsTeamProjectCollection tpc = new TfsTeamProjectCollection (wi.ServerUri)

VersionControlServer vcs = tpc.GetService ()

Workspace workspace = vcs.GetWorkspace (wi)

/ / Get the identity service for the TPC.

IIdentityManagementService ims = tpc.GetService ()

/ / Get the security service for the TPC and use it to get the workspace security namespace.

ISecurityService security = tpc.GetService ()

SecurityNamespace workspaceSecurityNamespace =

Security.GetSecurityNamespace (SecurityConstants.WorkspaceSecurityNamespaceGuid)

/ / Get the access control list for the workspace, using the workspace's security token in the namespace.

AccessControlList acl = workspaceSecurityNamespace.QueryAccessControlList (workspace.SecurityToken

Null, false)

/ / Get the full TeamFoundationIdentity objects for the IdentityDescriptor of each access control entry.

List descriptors = new List ()

Foreach (AccessControlEntry ace in acl.AccessControlEntries)

Descriptors.Add (ace.Descriptor)

TeamFoundationIdentity [] identities = ims.ReadIdentities (descriptors.ToArray (), MembershipQuery.None)

ReadIdentityOptions.None)

/ / Display the access control list to the user.

Console.WriteLine ("Access control list for" + workspace.DisplayName + Environment.NewLine)

Int I = 0

Foreach (AccessControlEntry ace in acl.AccessControlEntries)

{

If (null = = identities [I])

Console.WriteLine ("" + ace.Descriptor.Identifier + ":")

Else

Console.WriteLine ("" + IdentityHelper.GetDomainUserName (identities [I]) + ":")

If (0! = ace.Allow)

Console.WriteLine ("Allow:" + ((WorkspacePermissions) ace.Allow) .ToString ()

If (0! = ace.Deny)

Console.WriteLine ("Deny:" + ((WorkspacePermissions) ace.Deny) .ToString ()

ITunes +

}

Going back to the example of our "public-limited" workspace, we can now use this code to observe the complete access control list for this workspace.

Modify access control list

We can make further changes to the above code to manipulate the access control list. Let's remove the access control entry for [Collection0]\ Project Collection Valid Users and replace it with an entry that only grants all permissions to REDMOND\ vseqa1. Administer permissions are required to perform this operation on this workspace, and of course, users with global AdminWorkspaces authorization can also do so.

/ / Use the current directory to infer the workspace and TFS team project collection.

WorkspaceInfo wi = Workstation.Current.GetLocalWorkspaceInfo (Environment.CurrentDirectory)

TfsTeamProjectCollection tpc = new TfsTeamProjectCollection (wi.ServerUri)

VersionControlServer vcs = tpc.GetService ()

Workspace workspace = vcs.GetWorkspace (wi)

/ / Get the security service for the TPC and use it to get the workspace security namespace.

ISecurityService security = tpc.GetService ()

SecurityNamespace workspaceSecurityNamespace =

Security.GetSecurityNamespace (SecurityConstants.WorkspaceSecurityNamespaceGuid)

/ / Get the access control list for the workspace, using the workspace's security token in the namespace.

AccessControlList acl = workspaceSecurityNamespace.QueryAccessControlList (workspace.SecurityToken

Null, false)

WorkspacePermissions allWorkspacePermissions = WorkspacePermissions.Read | WorkspacePermissions.Use |

WorkspacePermissions.CheckIn | WorkspacePermissions.Administer

Acl.RemoveAccessControlEntry (new IdentityDescriptor (IdentityConstants.TeamFoundationType)

GroupWellKnownSidConstants.EveryoneGroupSid))

Acl.SetAccessControlEntry (new AccessControlEntry (tpc.AuthorizedIdentity.Descriptor)

(int) allWorkspacePermissions, 0), false)

WorkspaceSecurityNamespace.SetAccessControlList (acl)

After running this code, I can see that the access control list for this workspace has only two entries-one for the owner of the workspace and the other for me (REDMOND\ vseqa1).

Because the access control list for this workspace no longer matches the predefined "permission configuration" (template), this "permission configuration" is displayed as "Custom permissions" in the Edit Workspace dialog box.

If you set the permissions combo box of the workspace to "Custom permissions", you can change any of the properties of the workspace without rewriting the custom access control list. But if you want to switch back to the predefined "permission configuration" later, just select the appropriate "permission configuration" in the combo box and click "OK". Your custom access control list will be eliminated and replaced. What happens if I (the owner) accidentally delete my own ACE?

The version control permission check will succeed even if the owner's ACE does not exist in the access control list of the security service. The version control service knows that you are the owner of the workspace and that you have full permissions. You cannot change the access control list through the security service until the owner's ACE is restored. To restore the owner's ACE, you can open the Edit Workspace dialog box and make some random changes (for example, change description). When you click OK, on the server, the workspace will be updated and the owner's ACE will be restored.

These are all the details of how to analyze the improvement details of the workspace in TFS 2010. for more information related to how to analyze the improvement details of the workspace in TFS 2010, you can search the previous articles or browse the following articles to learn! I believe the editor will add more knowledge to you. I hope you can support it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.