The titled error message (above) often occurs when a number of people work on a particular server, using the same credentials. This article explains the different workspace permissions that can be assigned in Visual Studio, as well a way of eradicating the error message.
This post is only relevant to TFS 2010 and beyond. Any previous versions will only allow a workspace to use the ‘private workspace’ setting
When creating a TFS workspace and linking it to Source Control, the associated solutions (and files) are saved to a local location. By default, everything saved here is set with a ‘private workspace’ permission. As a result, only the associated user (that is logged on to a server) can create, edit or delete parts of the solution.
In most cases, you would want TFS to apply the ‘private workspace’ permission. This ensures individuals have their own copy of locally developed work and prevent the risk of anything being accidentally overwritten or deleted. However, there may be a need to share a workspace across multiple users, where the solution files are store on a shared drive. Furthermore, some servers use generic log in credentials (to a server), in which more than one person would connect to TFS. Switching the TFS workspace to a more ‘public’ setting would enable everyone to share the same solution files.
There are 3 types of workspaces in TFS 2010 (and beyond);
a. Default setting and most commonly used. Only the logged in user will be able to create, edit or delete from the local files. In effect, only the owner will have permissions.
a. Additional users are granted the Read and Use permissions on the workspace.
a. Every valid user of the team project collection has the same permissions as the owner: Read, Use, CheckIn, Administer.
Edit TFS Workspace Settings
The below instructions illustrate how to change a workspace permission in Visual Studio 2010. The same logic applies to Visual Studio 2012 and 2014.
1. From the File menu, click Source Control, and then click Workspaces.
2. In the Manage Workspaces dialog box, under the Name column, highlight the workspace that you want to modify, and then click Edit.
3. In the Edit Workspace dialog box, Click Advanced.
4. Change to the desired workspace by using the ‘permissions’ drop down.
Fig 1.0 – Edit Workspace Example
5. Click OK to confirm.
Test Workspace Permissions
You’ll need to log onto the machine which has the public workspace. After starting Visual Studio 2010 and connecting to the server which has a public workspace, you’ll be able to see the workspace in the appropriate drop-down combo boxes in the Source Control Explorer and Pending Changes tool windows.
1. From the Team Explorer home page (Keyboard: Ctrl + 0, H), choose Source Control Explorer.
2. From the menu bar choose View, Other Windows, Source Control Explorer.
3. Choose the recently changed ‘Public Workspace’ and begin to use it.
Although the original TFS error message was the reason for my findings, it also highlights the fact that there are now different workspace permissions that can fit your needs. To any users of TFS and Source Control, these types of articles are priceless when learning more about it.
Visit the websites below for a more in depth look into workspaces: