44

We are trying to follow the branching strategy from the TFS Branching Guide and have reached the point where we have made a branch representing a release, which should now be made read-only.

In the Properties|Security tab for the branch, it presents six user groups each with 10 permissions other than Read. Do I have to go through and click Deny on 60 check boxes, or is there a better way to make this branch read-only?

Mark Heath
  • 48,273
  • 29
  • 137
  • 194

6 Answers6

52

Right-click the branch in the Source Control Explorer, and select the Lock... option

EDIT: This seems to get missed a lot when people are finding this so I'll make it more obvious.

Locks appear as a "pending change" for the person who locked the item. As long as the lock is in effect, it will appear as a pending change. When a commit is made of that pending change, the lock is released. While the lock is in effect, the locked branch is effectively read-only, since (to simplify) the locker is the only user who can make commits. The act of committing is what releases any locks on the branch.

h/t @AakashM for pointing that out in the comments

Josh E
  • 7,390
  • 2
  • 32
  • 44
  • 21
    This leaves the lock hanging around as a pending change. Removing check-in permissions is the right answer. – Ian Goldby Aug 16 '12 at 08:37
  • 1
    +1 The lock simply doesn't work... As a locker, I have the "add lock" change pending, and on top of that, I can go and check-in files freely. Changing permissions works better IMHO. – Etienne Oct 08 '12 at 05:10
  • 1
    Added the lock, tried to commit and the server responded with " All of the changes were either unmodified files or locks. The changes have been undone by the server." – amhed May 24 '13 at 13:42
  • 1
    as @AakashM says in the comments to his answer, "...clicking Check In with the lock item checked is what releases the lock. It's... somewhat unintuitive." – Josh E May 28 '13 at 14:50
  • Nice ... amazing user interaction. I've been trying to fix the 'unlocked' branch when I checked it in for 2 hours ... argh :\ Thanks for pointing it out. – Ignacio Soler Garcia Nov 12 '15 at 12:16
  • The only problem is now I keep getting asked to check in. – xr280xr Jun 17 '19 at 20:36
11

As a quick-n-dirty, you could Lock it for Check Out (although the locker would have to remember to keep the lock in their pending changes forever... which makes me think there's a better way)

AakashM
  • 62,551
  • 17
  • 151
  • 186
  • the locker wouldn't have to remember to keep the lock - it would just prevent check-ins. The best strategy in that case is for Devs with pending changes to shelve them on the server. – Josh E Jun 24 '09 at 14:11
  • What I mean is that the Lock sits in the lockers pending changes window as if it were an actual 'pending change' - and clicking Check In with the lock item checked is what releases the lock. It's... somewhat unintuitive. – AakashM Jun 24 '09 at 14:15
  • 10
    I have a "management" workspace where I perform merges, hold locks, etc. That way I don't see them during day to day development. – Richard Berg Jun 25 '09 at 15:23
  • @JoshE, What about having a dedicated account for locking things -->LockUserAccount, only this account can Lock and Unlock things? – Legends Jul 23 '16 at 00:28
  • @Legends nothing stopping you from doing that, but I'm not sure what value you'd get... you'd still need to deal with the pending changes of locks/check-in for unlocks, it'd just be a step removed from before – Josh E Aug 05 '16 at 18:18
9

To answer the 2nd part of the question -- removing or denying the Read permission effectively denies everything else.

Richard Berg
  • 20,629
  • 2
  • 66
  • 86
5

As is mentioned above locking is not a very nice strategy. The correct way of handling this is setting permissions.

You can effectively make files readonly. Users trying to modify the files will get a message 'checkout denied'

https://msdn.microsoft.com/en-us/library/ms252587.aspx#project_level

In VS2013: Team Explorer -> Settings -> Security/Version Control

FrankyHollywood
  • 1,497
  • 19
  • 18
3

Deny Check In for domain\domain users

AndySw
  • 341
  • 2
  • 7
2

If you have inheritance set to 'On', the best way I've found is to:

  1. 'Deny' all permissions except 'Read' to the 'Reader' group, and
  2. Add all other groups (except Project Administrators) to the 'Reader' group.

Then, all groups within the Reader group will inherit the 'Deny' permissions and not be able to do anything but read.

alex
  • 141
  • 1
  • 2
  • 7