Locks based on file types (extensions) and shelving

Recently, someone asked about locks, shelving, and buddy builds (i.e., shelving your changes and unshelving and building them in another workspace to make sure everything builds cleanly).

I am trying to add a number of files into our source control.  The list of files I want to add contains a few each of .ico and .bmp, and one .xls files, all which get locked (locked to prevent check-out) when I add them, presumably because they cannot be merged if someone else checks them out and changes them.

The fact that they get locked seems to deny the possibility of buddy building, even on my own second machine, because they are locked on a by-workspace rather than by-user basis.

I tried selecting the binary items in the hierarchy under the Source Control Explorer, and right-clicking to the “unlock” command, but it always says that the file could not be found in my workspace.

What am I missing?  A preference setting or checkbox somewhere that does not lock added binary files?  Is there some way to turn off or override my own lock?  Is it really not possible to unshelve shelvesets containing binary files to a second machine?

Locking and shelving, while keeping the changes in your workspace, don't mix.  The files that are configured to be locked via file type extension (in VS, Team -> Team Foundation Server Settings -> Source Control File Types) are locked exclusively.

An exclusive checkout lock prevents any other changes from being pended on the file involved.  The file type locking mechanism prevents user from unlocking files that are locked via that mechanism.  So, to do a buddy build, you would need to shelve and undo, which is best accomplished by either unchecking the “Preserve local changes” checkbox in the GUI shelve dialog or using the /move option on the shelve command.  Alternatively, you can change the file types to allow multiple checkout.

The problem is even worse for users where exclusive checkout is turned on for an entire team project, as even plain text files are locked exclusively in that case.  As with the file type extension locking mechanism, users cannot unlock files that are locked due to the team project setting.  When you shelve, you need to move the changes to the shelveset (don't keep them in your workspace).

For us, the file type locking causes problems both with buddy builds and with a check-in system we use called gauntlet.  With gauntlet, we shelve our changes and submit them to gauntlet for it to build them and check them in.  It can't unshelve any item that requires an exclusive lock if you still have the pending change in your own workspace.  As a result, we've turned off exclusive checkout based on file extensions by changing each to allow multiple checkout.

Comments (4)

  1. I hit another TFS snafu on Tuesday which I thought I’d share. MSBee has a unit tests project which currently…

  2. Tommy says:

    I just ran into the same thing. Although locking a file could be a good thing in some situations, its usually bad. Plus, why can’t I unlock my own ‘locks’.  I have to get on that certain workspace and unlock it.  That seems simple enough, until you find out that the workspace is limited to the computer it was created on, so if you have a workspace on a home machine and your at work, well, your outta luck!

    For as much as TFS costs, I think its pretty terrible.  I would much rather use SVN and an issue tracking system like Trac then this piece of garbage that cost mucho dinero.

  3. buckh says:

    You can unlock files you’ve locked on a remote machine using the lock command, unless the lock is due to being in the file extension list.

    I’m curious to know what has brought you to the conclusion that TFS is terrible.


  4. Tom says:

    I agree with Tommy.  Specific points:

    Why can’t TFS tell me what files I’ve changed without contacting the server?  Every other source control system on earth can do this.

    Why does TFS tell me ‘All files are up to date’ when I say ‘Get Latest’ even if I’ve changed files locally?  I understand that editing without checking out does not really fit into the TFS model, but the message is just plain wrong.  Which brings me to my next point…

    Why doesn’t TFS support edit-merge-commit?  Every other source control system supports this.  Even sourcesafe had a workaround to make it work.

    Why does TFS complain about merge conflicts when merging a branch back to the trunk when only one of them has changed?  Just plain wrong.

    Why can’t someone else unshelve a shelfset that contains binary files unless I undo the changes in my workspace first?  Providing shelfsets and thinking that people are not going to use them for reviews is delusional; requiring that I stop working on something before someone reviews it is just wrong.

    If my workspace has one TFS path checked out inside another TFS path, why can’t TFS figure out that I don’t want the subsidiary path to show up in comparison results?  Or, even more usefully, compare the subsidiary path to its server location?

    Why doesn’t the "tree compare" tool present the comparison results as a… erm..  tree?  Like, so I can collapse parts of it I’m not interested in?  Only a UI thing, I know, but easily the most annoying thing about working with TFS.

    Why do the commit notification emails include hyperlinks to completely useless pages that won’t show me the changes in the changeset?

    Some of these are alleviated by binding a VS Solution to the TFS server, but then why does it take VS over a minute to figure out that I’m not connected to the network any more when I take my laptop home?

    Why can’t I move multiple files?  Why do I have to select each one individually, right-click, select Move, put the new path in?  Drag-and-drop is far too new a concept for TFS, apparently.

    The list goes on, rather, I’m afraid.  These are the ones that have annoyed me in the last day or so.

Skip to main content