This project has moved and is read-only. For the latest updates, please go here.

Make Branch Read Only

Dec 21, 2010 at 6:39 PM
Edited Dec 21, 2010 at 6:39 PM

In the branching guide it is recommended that once a release goes live that release branch be made read only.  From what I can find that is a simplification of what is required to make a branch read only.  Is there any guidance on how to perform this task?  What I have seen is a manual process for each security group of explicitly denying permissions.  Is there a simpler way that I am overlooking?


Dec 21, 2010 at 7:08 PM

I think you nailed it. I have been waiting for somebody to post this question. As you note, there is no simple read-only property you can set. :(

Bill Heys
VS ALM Ranger

Dec 2, 2011 at 12:15 PM

You can do that by locking the branch. It will prevent users from code check-out and check-in.




Dec 3, 2011 at 3:21 AM

Bill, what do you typically recommend in this case? Do you set the Deny permission on all permissions for every project group? I have found what I thought was a clever way to do this but I want to get your opinion. I did the following:

1. right-click the branch or folder in question, and choose Security

2. Add Team Foundation Server Group "Project Collection Valid Users"

3. Set deny on all items except Read and Manage permissions.

Then EVERYONE in the project collection is locked out by clicking the deny settings in one place, one time. Having to change settings for multiple groups is error prone.  And it is easily reversed by someone with sufficient authority. That reversal capability is great to prevent unintentional hassles. But since the setting can be changed back and forth indefinitely, auditors would have to view history and examine to ensure no changes were made after launch date, since an administrator could remove the Deny, make a change, and reapply the Deny.  There wouold be no evidence of the security change, though there would be evidence of the code change.

Dec 3, 2011 at 1:21 PM


I typically follow a process similar to yours. I am not too concerned about an administrator bypassing the intent of locking down a release branch. They will be cautioned that if this happens, their job will be posted shiortly thereafter.