|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Understanding Lock Types
You can use the lock command to temporarily prevent changes to a particular file or folder in the source control server. This can be helpful if you want to change an item in your workspace and then check in without being forced to resolve any merge conflicts. Only one user at a time may hold a lock on a particular file or folder. If you want to prevent access to an item in a persistent way, you should use the Permission Command instead.
Team Foundation provides two types of locks: check-in locks and check-out locks.
A check-in lock is less restrictive than a checkout lock. When you apply a check-in lock, users can continue to make local changes to the item in other workspaces but those changes cannot be checked in until you explicitly remove the check-in lock from the item or remove it implicitly by checking in your changes to the file.
A check-out lock, which is more restrictive than a check-in lock, prevents users from checking out and making changes to the locked item in their workspaces. You cannot apply a check-out lock to an item for which any pending changes exist, in any workspace other than your own. Therefore, a check-in or check-out lock guarantees the right of first check-in to the holder of a lock in the workspace where it is locked.
If a file is checked out when you lock it, its check-out record is modified to contain the new lock type. If the files are not checked out, a "lock" change is added to the set of pending workspace changes. Unlike the checkout command, the lock command does not automatically make a file editable.
Team Foundation unlocks an item automatically when you check in pending changes in the workspace where it is locked. Locks are also released if the pending changes for a file are undone using the undo command.
Locks on folders are implicitly recursive. If you lock a folder, you do not have to lock the files it contains unless you want to apply the more restrictive check-out lock to a file in a folder that has a check-in lock.
Only one user at a time may hold a lock on a particular file or folder. You can learn which files are locked in the Team Foundation version control server and by whom they were locked using the Status Command.
A lock may be placed either as its own operation or as part of several other operations including rename, checkout, delete, undelete, merge, branch, and add to source control. When you lock an item as part of an add to source control or branch operation, Team Foundation places the lock on the server path where the new item will be created. This prevents another user from adding or branching a file to the same location. When you lock an item using the rename command, both old and new server paths are locked.
You can unlock an item explicitly by using the unlock command or implicitly during check-in. When you check in pending changes to a locked item, Team Foundation removes any locks.
By default, the UnlockOther permission is granted to administrators only. If you have the UnlockOther permission, you can remove a lock from an item in another user's workspace by using the Lock Command.