In a TFS 2010 collection database, where is the database flag the identifies if a folder is cloaked within TFS?
Asked
Active
Viewed 268 times
0
-
Do you mean cloaked within a given workspace? – Taylor Lafrinere Aug 30 '12 at 22:16
-
As Ed noted below, you should really avoid the database schema directly. The team can and will change that as needed. The SDK public OM has compat requirements between releases. – bryanmac Aug 30 '12 at 23:22
1 Answers
3
The cloaked flag for a folder is per user's workspace. It is not a good idea to read\write this information directly from the database because the schema is subject to change. Explain what you want to accomplish and I suspect you can accomplish it using the object model (OM) of the TFS SDK.
The Workspace class (in the TFS SDK) has a property called Folders which is an array of WorkingFolders (see here) which has an IsCloaked property. This is the recommended way to find cloaked folders in a workspace.

Ed Hintz
- 864
- 6
- 7
-
We need automated zero client SSRS reporting for management. Audit requires us to remove Read, Check Out/In, Label, & Lock permissions from devs after code freeze to keep the branch consistent with what was deployed. Developers aren't allowed to branch or merge their own changes (handled by my team). We cloak their uniquely named branch folders after changes are deployed. For us to see what projects are active (check out/in permissions for their security role & if a branch is cloaked). Having 10-30 branches per release & 2-3 releases per month makes reporting capability a necessity for my team – Jason Aug 31 '12 at 11:49
-
I've got a few questions on your scenario. Their is likely an easy way to do what you want to do. It sounds like your developers are doing all of their work in private branches off of a main branch that you deploy from. Is this correct? It seems like you could simply lock down the deployment branch using permissions and not alter the developer's branch in any way. What is the reason you need to modify the developer's branch and why are you trying to use cloaks instead of permissions? – Taylor Lafrinere Aug 31 '12 at 16:53
-
@TaylorLafrinere We are creating branches both from main and branch to branch (more rare). Permissions are taken away from the "active" branch during code freeze. The development branch is the same as the release branch in our system. The trunk is always locked from the developers because it is to reflect current prod. We cloak to give the developers a "cleaner" look so once they open up a project it doesn't have an unreasonable amount of branched folders (per management). Our process is different than recommended and will not be changed anytime in the near future, hence the cloaked flag Q – Jason Aug 31 '12 at 17:19
-
If you simply remove read access (that is, deny the read permission) on the source-controlled folder/branch then developers will not be able to see the folder/branch which will accomplish your goal of giving a "cleaner" look. You shouldn't need to mess with workspace cloaks at all. Is there any reason that doesn't work? – Taylor Lafrinere Aug 31 '12 at 21:57
-
Should or shouldn't is somewhat irrelevant. It is a decision coming from management so it would be really helpful to know where this information is stored in the DB. Can anyone help? – Jason Sep 05 '12 at 11:22