What is the purpose of a shelveset?

Question

I've been using TFS for a while now but as a lone developer I haven't really used its features to its full extent. I've now been tasked with working with a couple of colleagues overseas and we will be using a shared version of TFS. One of their processes is shelving, however I'm not sure on the how to use this. I decided to have a play, but I'm unsure what to do after creating a shelve set. My process was as follows:-

I opened an existing project from TFS that was fully checked in and made a simple change to one of the files. I then created a shelve set. I then closed the project and reopened it from source control. I noticed the change I had made was not applied which was correct however the file was still checked out to me. Its at this point my confusion starts. If I create a shelve set am I supposed to do an undo pending changes so that the original files are checked back into TFS so my colleagues can use them or create a build from them.

I'm a bit confused on the process.

Answer 1

In my experience shelvesets are typically used for 3 purposes:

1. Switching Tasks before I'm ready to Check-In
2. Getting help from colleagues on code that isn't working
3. Code Reviews

When you create a shelveset you have a checkbox to choose whether you want to undo your pending changes at the same time or not.

For #1, I would want to check the box to undo my changes, as the entire purpose of shelving is to get a clean local workspace to start on the new task.

For #2, I would probably not undo my changes, as after the colleague has looked at my code and helped me I will want to continue working on those changes.

For #3 this is only applicable if the code review workflow is pre-checkin, in that case you would typically undo your pending changes so you can start working on the next item while waiting for the review and not comingling the changes.

Answer 2

Just for reference, this MSDN link provides the usage of shelvesets as:

• Interruption: You have pending changes that are not ready for check in, but you need to work on a different task.
• Collaboration: You have pending changes that are not ready for check in but you need to share them with another team member.
• Code Review: You want another team member to perform a code review of your pending changes.
• Private Build: Before you check in your changes, you can use your automated build system to build and test your code.
• Backup: You have work in progress that you cannot finish now so you want a backup copy that is stored on your server and available to other team members who might need to access it.
• Handoff: You have work in progress that you want to hand off to another team member.

Answer 3

From a process perspective (in an agile shop) the primary use is to ensure your code builds with the existing code without breaking the build on your integration branch for the rest of your team. The items noted above will help you accomplish this task.

In short: never check anything in if it does not build correctly. Shelf your code to ensure it works and does not break the build before checking it in. If you do break the build for your team, your nightly builds (if you have them) won't work, so your testers will not have the new code base to work with.

Note: your code might be buggy at first but that's ok, just don't break the build. If your code is not mature enough to be tested (breaks something or perhaps the entire app), ensure your code is inactive in the application. There are lots of tricks for doing this from simply commenting the code out so you can check it in to adding an exception of some kind to prevent the code from running unless you set a variable during your debug. I am sure there are million other things you can do as well.