WHITESPACE_HERE
Today I solved a pesky problem with Team Foundation Server: sometimes, some developers (but not others) could check into a branch even though all permissions had been denied.
My group does all development in the source code trunk, then branches at the end of any iteration that we intend to take up to our production environment. After early bug fix work on the branch we lock the branch down. Thereafter, developers have to ask for permission to check into the branch. This ensures that we know exactly what is being checked in, and when. And we can decide, on a case-by-case basis, whether to allow it–no one wants a surprise going out to production.
WHITESPACE_HERE
So why could developers sometimes check into the branch even though all permissions had been denied?
WHITESPACE_HERE
As the TFS administrator (for the first time), I had beat my against this without ever getting anywhere. And recently I figured out the problem.
The key was to realize that the problem was described inaccurately.
Incorrect definition: sometimes a developer could get into a branch when I had (or thought I had) denied it.
Correct definition: that developer could ALWAYS get into a certain part of the branch, but not into other parts. Other developers might be denied in some areas but not others, too, but not the same parts as the first developer. Since all developers may sometimes work in any part of the branch the end result seemed somewhat random but that was not the case.
WHITESPACE_HERE
How does it happen?
WHITESPACE_HERE
Our source code tree is rather cluttered, and when I cut the branch intended for production, I end up actually branching several separate parts of the trunk, based on a common label, into a new, single destination root for the branch. I administer permissions to the branch at the root of the branch.
The problem: some subtrees in the trunk had explicit permissions granted to them rather than inheriting from higher up the source tree. These explicit permissions carried over into the branch, overriding the permissions I set at the root.
Very simple, once I understood it.
The solution was to keep an eye on where permissions were explicitly granted in the trunk, and remove those permissions in the branch so that all permissions get inherited from the root of the branch. It would also be helpful to see where I can eliminate those explicit permissions and allow inheritance to do its work.
This fits the needs for my group, based on our local needs and the structure of our source code (which I inherited and do not like but am probably stuck with for a long time). It may not fit yours–but understanding that explicit permissions in a subtree of the trunk carry over into a branch may help you fix your own problems someday.