What is Shelving in TFS? just a soft checkin so others can see code?

Question

Hi,

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?

Answer 1

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

Answer 2

You're right. Shelving is used to backup and share code. It is not compiled.

Answer 3

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.

Answer 4

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

Answer 5

Shelving has many uses, the main ones are:

1. Context Switching: saving your 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 w/o 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?

Answer 6

I keep reading about shelving changesets for code reivew, before the code is checked in. How do you create a changeset without checking the code in?

Thanks, Bob