On Babies And Shelvesets

One of my co-workers is expecting his first baby any day now, and yet at the same time we've saddled him with some rather large changes that spread across all areas of our code base. The fall back, in case he cannot complete the changes to a suitable state for check-in by the time the baby arrives, has been for him to "shelve early and often". Basically, if he walks away from the computer we want him to shelve his code into TFS. This way, if he doesn't come back to the computer for a few days because a stork knocked on his door, I can just un-shelve his changes and finish up the leftover bits.

This seemed like a great plan; many backs were slapped, high-fives initiated (and returned!) and egos inflated. We are genius! So I don't know about the other guys, but I've been sleeping like a newborn baby knowing that all our bases were covered. I think you know where this is going. Except it's not. But it almost did.

Basically, papa-to-be was curious why some tests were failing and asked if I could unshelve his latest change and give it a look-see. When I went to do so, I got the following lovely error:

SupportTestData.xls is locked for check-out by INSERTCOWORKERHERE in workspace COWORKERSWORKSPACE.

Umm, that's not good. You see, xls is binary, so you can't share a check-out. And I can't download a shelveset unless I can check out every file. This is apparently a 'feature' of TFS, because hey, shelving isn't made for sharing, that's just a nice side-benefit, so don't expect it to always work the way you hoped it would.

Thankfully we discovered this pre-stork. Now we have the knowledge that he can simply undo his pending changes following his shelves, ensuring that there are no locks if he never comes back.