[tfs] What is Shelving in TFS?

Is shelving in TFS merely a soft checkin so other team members can see the source code?

i.e. the shelved code will not be compiled right?

I come across this all the time, so supplemental information regarding branches:

If you're working with multiple branches, shelvesets are tied to the specific branch in which you created them. So, if you let a changeset rust on the shelf for too long and have to unshelve to a different branch, then you have to do that with the July release of the power tools.

tfpt unshelve /migrate

Shelving is like your changes have been stored in the source control without affecting the existing changes. Means if you check in a file in source control it will modify the existing file but shelving is like storing your changes in source control but without modifying the actual changes.

@JaredPar: Yes you can use Shelvesets for reviews but keep in mind that shelvesets can be overwritten by yourself/others and therefore are not long term stable. Therefore for regulatory relevant reviews you should never use a Shelveset as base but rather a checkin (Changeset). For an informal review it is ok but not for a formal (E.g. FTA relevant) review!

If you're using Gated builds, when a build is triggered, it creates a shelveset of your workspace that is submitted for build. If the build fails, the shelveset is rejected. If the build is successful, a changeset is created and committed to TFS. In either event, the person doing that check-in/build will have to reconcile the workspace, which is as simple as performing a Get Latest.

Shelving is a way of saving all of the changes on your box without checking in. The changes are persisted on the server. At any later time you or any of your team-mates can "unshelve" them back onto any one of your machines.

It's also great for review purposes. On my team for a check in we shelve up our changes and send out an email with the change description and name of the changeset. People on the team can then view the changeset and give feedback.

FYI: The best way to review a shelveset is with the following command

tfpt review /shelveset:shelvesetName;userName

tfpt is a part of the Team Foundation Power Tools

One point that is missed in a lot of these discussions is how you revert back on the SAME machine on which you shelved your changes. Perhaps obvious to most, but wasn't to me. I believe you perform an Undo Pending Changes - is that right?

I understand the process to be as follows:

1. To shelve your current pending changes, right click the project, Shelve, add a shelve name
2. This will save (or Shelve) the changes to the server (no-one will see them)
3. You then do Undo Pending Changes to revert your code back to the last check-in point
4. You can then do what you need to do with the reverted code baseline
5. You can Unshelve the changes at any time (may require some merge confliction)

So, if you want to start some work which you may need to Shelve, make sure you check-in before you start, as the check-in point is where you'll return to when doing the Undo Pending Changes step above.

Shelving has many uses. The main ones are:

1. Context Switching: Saving the work on your current task so you can switch to another high priority task. Say you're working on a new feature, minding your own business, when your boss runs in and says "Ahhh! Bug Bug Bug!" and you have to drop your current changes on the feature and go fix the bug. You can shelve your work on the feature, fix the bug, then come back and unshelve to work on your changes later.
2. Sharing Changesets: If you want to share a changeset of code without checking it in, you can make it easy for others to access by shelving it. This could be used when you are passing an incomplete task to someone else (poor soul) or if you have some sort of testing code you would never EVER check in that someone else needed to run. h/t to the other responses about using this for reviews, it is a very good idea.
3. Saving your progress: While you're working on a complex feature, you may find yourself at a 'good point' where you would like to save your progress. This is an ideal time to shelve your code. Say you are hacking up some CSS / HTML to fix rendering bugs. Usually you bang on it, iterating every possible kludge you can think up until it looks right. However, once it looks right you may want to try and go back in to cleanup your markup so that someone else may be able to understand what you did before you check it in. In this case, you can shelve the code when everything renders right, then you are free to go and refactor your markup, knowing that if you accidentally break it again, you can always go back and get your changeset.

Any other uses?

That's right. If you create a shelf, other people doing a get latest won't see your code.

It puts your code changes onto the server, which is probably better backed up than your work PC.

It enables you to pick up your changes on another machine, should you feel the urge to work from home.

Others can see your shelves (though I think this may be optional) so they can review your code prior to a check-in.