How to prevent Team Foundation undoing locks

Question

I've been working with Team Foundation for a short while now, and I'm finding one behaviour particularly annoying. Say I have several Team Projects:

$/
  Project1
  Project2

Now, for reasons we don't really need to get into, I'm wanting to keep $/Project2 locked, to prevent anyone else doing anything to it. Normally, whenever you do a check-in at a particular level of the tree, everything at that level and below is included in the check-in.

However, in this case, whenever I do a checkin to anything under $/Project1, included in the list of items to check-in is the lock on $/Project2. If I just hit OK, my lock disappears. Is there any way to prevent this behaviour?

Answer 1

Use different workspaces. Locks, checkouts and checkins are scoped to the workspace.

Once the workspaces are set up their use is largely transparent (especially if you select to get latest on checkout).

Answer 2

My first suggestion would be the same as Richards, use a different Workspace.

Another way is not to use locks at all but to modify the security permissions on the team project so that only you are able to check files in to it. To modify permissions right click on the folder in Source Control Explorer, select Properties... then the security tab.

You can un-check the "Inherit security settings" box and then allow or deny as you see fit. However be very careful when editing the security as you can easily accidentally set the folder so that even you cannot see it to revert the settings back. See the following top tip if you get yourself into that situation:

• TFS Top Tip #5 - What to do if you lock yourself out of your repository

Answer 3

I agree you should use a separate workspace for "long-lived" locks. Makes life much easier. You don't even need to make a folder on disk -- just map $/ to someplace random, click No when prompted to sync, and Lock away.

BUT...

Normally, whenever you do a check-in at a particular level of the tree, everything at that level and below is included in the check-in. However, whenever I do a checkin to anything under $/Project1, included in the list of items to check-in is the lock on $/Project2.

I can't reproduce this. Using VS 2008 SP1, I see the same behavior I always do: the complete list of pending changes in that workspace is shown in the Checkin modal dialog, but only the items scoped to my right click (either from SCE or Solution Explorer) are checked.

Maybe you're using the Pending Changes toolwindow? I use it all the time, but one thing it doesn't do is scope itself to any particular folder. That said, it does have one far-too-hidden feature that the other Checkin entry points do not: a "filter by solution" button. It's the rightmost icon before the Workspace dropdown. You might find it useful -- and not just in this case.

Answer 4

I think I've fathomed this out now.

As Richard Berg stated:

the complete list of pending changes in that workspace is shown in the Checkin modal dialog, but only the items scoped to my right click (either from SCE or Solution Explorer) are checked.

However, what I observe is that this is true for files; however, for folder related actions, all pending folder changes are also always included. And since the lock I was keeping was on the folder, that's why it was ticked in the pending changes list.

I agree with the others (and have upvoted) that using separate workspaces is a better solution going forward, but at the time I had a lot of changes pending under that locked folder, so it wasn't practical to switch workspace.