通过

Locking functionality in Team System Version Control

  • 项目

After my last post, I received some questions about locking as it relates to changesets. So here's a brief description. As always, if I'm not clear or I'm leaving you confused, please let me know - constructive criticism is always welcomed :)

By default, multiple people can check out a file at the same time.  Naturally, if multiple people make changes to the same file at the same time, the possibility of a merge conflict arises.  If you want to prevent this from happening, you can apply one of two different lock types.

A checkout lock blocks others from checking an item out for edit/rename/deletion, etc. (really, any pending change) until the lock is lifted. When the owner of the lock checks in the locked item, the lock is removed. The owner can also choose to remove the lock before he/she checks the item in.

A checkin lock allows other users to pend changes to an item, but prevents them from checking in until the lock is lifted.

Here's a quick example:

   tf checkout /lock:checkout main.cs

Altenatively, you can use the lock command to manage locks:

   tf lock /lock:none main.cs

In the example above, we're removing a lock previously held on the file main.cs. A user can only unlock a lock held by another user if they have permission to do so. Such permission can be granted to individual users or to groups of users, such as trusted source control system administrators.

Note - A Team System administator has the option to enforce auto-lock for all checkouts, allowing Team System to mimick other common version control systems.

Comments

  • Anonymous
    November 19, 2004
    Some wht unrelated question... would you be able to comment on parallel development... specifically branching/merging strategies and implementations with tf?
  • Anonymous
    November 19, 2004
    Sure thing - thanks for the suggestion. Do you have a specific question about whether a certain strategy is supported or how it would be implemented with Team System, or are you looking for more of an overview of the features with some discussion of which strategies they could enable?
  • Anonymous
    November 29, 2004
    Anything you could offer would be great. Since my last post I have a test suite with many cases and H deliveries on some ... but some of the more complex parallel cases I cannot seem to get the appropriate functionality. Any comment you could provide on this case below would be appreciated

    Let say we have a trunk, and two development lines...
    BASE
    STREAM1
    STREAM2

    where
    10file.txt exists in base

    10file.txt was renamed to rename.stream1.10file.txt in Stream1
    rename.stream1.10file.txt had its contents modified in Stream1

    10file.txt was renamed to rename.stream2.10file.txt in Stream2
    rename.stream2.10file.txt had its contents modified in Stream2

    after the issuing
    h merge Stream1 Base
    h checkin /i
    h merge Stream2 Base

    the conflict / resolve window does not provide and option to "merge changes AND choose the desired file name" ... it only allows for to accept source file or target file...

    Again, this is a complex case that occurs infrequently, but if its not flaged / caught by the SCM tool, it tends to manifest itself as a broken build at the worst possible time, making the SCM guy look bad :)


  • Anonymous
    December 20, 2006
    So, this has been awhile coming. Let's blame that on the combination of 2 zillion screenshots and the