My voice is my passport

Locks vs. Permissions

 

Visual Studio's Team Foundation Version Control has a very powerful access control model, permitting administrators to grant groups and individuals only the specific capabilities they need to do get the job done. Team Foundation provides two ways to control the abilities of authenticated users to use version control. You can either temporarily lock items or permanently set the users’ permissions. While both of these methods can be used to achieve some of the same ends, it’s often preferable to use one over the other.

 

This is a brief overview of how these two access control mechanisms work to help you decide what’s best for you. We’ll first review the basics and then investigate the areas where they overlap. Specifics may vary depending on particular infrastructure, but there a few general guidelines to follow.

 

Locking

 

Locks can be placed on any version control item stored on the Team Foundation Server. If the lock is on a folder, it is implicitly recursive and thus applies to all sub-folders and files. Locks are considered “pending changes”, though they behave slightly differently from other pending changes. Instead of becoming active when checked in, they are active until checked in or undone. Therefore, they are a quick and temporary way to prevent others from changing items on the server.

 

Types of locks

 

There are two types of locks- check-in and check-out. Check-in locks prevent other users from checking in pending changes on the locked items, while check-out locks prevent people from pending changes at all. If other users already have pending changes on an item, you cannot lock that item for check-out. In this sense, a check-out lock is more powerful than a check-in lock since it prevents users both from pending changes and checking them in rather than just the latter.

 

Locking rules

 

When locking a version control item, a few values are checked to make sure the lock can be set. First, users may only lock an item if they have the “Lock” permission on it. In addition, only one lock may apply to a given item at a time. Since this also applies to recursive locks, a user may not lock an item whose parent is locked by someone else. Conversely, a folder cannot be locked by someone if another user has a lock on a child of the folder.

 

Permissions

 

Permissions define the actions that groups and individuals are allowed to enact on the Team Foundation Server. It’s important to note that permissions are associated with items, though not with a particular version thereof. For example, if there are three versions of a file, there is no way to grant a user read access to only the first two.

 

Global vs. Item

 

There are two types of permissions. Some apply to the whole system, while others affect individual files and folders. These are “global” and “item” permissions, respectively. Item permissions may be inherited, and generally are by default. However, you may tell an item not to inherit permission. You may also override inherited permissions by explicitly setting them on a given item.

 

Setting permissions

 

Permissions take effect as soon as they are set, and remain in effect until they are changed. Of course, as mentioned above, permissions apply to all versions of the affected items. This does not undo actions which have already occurred, however. This applies both to global permissions and item permissions. Pending changes on an item are not undone if a user loses the PendChange permission. If a user makes a workspace while they have the “CreateWorkspace” permission, their workspace does not disappear if they later lose this permission. They may continue to use the workspace as long as they have appropriate permission to access the server.

 

Preventing change

 

There are two permissions in particular which allow users to change items on the server. The first is “PendChange” which allows users to add, branch, edit, merge, rename, delete, and undelete items. The second is “Checkin” which allows the users to check in the changes they pended.

 

Head to Head

 

So, let’s review some of the important differences:

 

	Lock	Permission
Duration	Until check in	Until changed
Can turn off inheritance	No	Yes
Per-user access control	No	Yes
Restore previous state with Undo (or unlock to keep other changes)	Yes	No
Can be set with current pending changes	No for “check-out”, Yes for “check-in”	Yes
Prevent new changes	Yes for “check-out”, No for “check-in”	Yes

 

What does this mean for you? Well, here are a few examples:

 

1) Joe Developer is working on a hot fix for an important customer. While working on the task, he locks the relevant files for check-in to make sure that no one else checks in changes to the infrastructure until after his fix has gone in. When he checks in the files, they become unlocked and other users can get the new version to merge their changes and check in.

2) The Ajax Company has hired a few summer interns. While they begin to learn the ropes, they’re required to pass all of their code to a full time employee for verification and checkin. The admin denies the group “Summer Interns” the Checkin permission on the whole tree. Instead, they can pend changes, shelve them, and then ask a coworker to unshelve them for review.

3) Sally Architect needs to make some overarching changes which she knows will be difficult to merge with other changes. She locks the items for check-out to prevent anyone else from modifying these classes (since merging with Sally’s changes would be a headache). When she checks her changes in, users may once again pend changes on those items.

4) Product Foo has just entered version 2, and the previous version has been branched to a separate folder. On the version 1 branch, the admins turn off inheriting permissions and only allow individual users the PendChange and Checkin permissions as needed for hot fixes.

 

These are just a few examples of when each type of access control is useful. Though we could achieve similar behavior with either, each is particularly tailored for certain types of situations.