Shelving code in Team Foundation Server (TFS)

Question

I'm pretty new at using TFS and I'd like to know how you or your team use the "shelve" function of tfs.

We have the following guidelines in using TFS: - perform a "Get Latest" before you check in and try to build/compile - do not check in code that does not compile - at the end of the day, if your work is not complete/partially done, you should "shelve" your pending changes

The first two make sense but I don't really get the last one. I asked my mgr and he said that its so he knows that you actually did some work for that day, which does kind of makes sense but still, I'm wondering what other teams use the "shelve" function for?

Answer 1

I personally have Multiple reasons to shelve:

• I want/need to go home but the current code would beak the build when it would be checked in.
• it is a backup
• if I would get sick, other members of my team would be able to get my changes and work on them
• sometime I am making a change and want to start over but not lose all the code that I have written sofar. Something might be usefull
• exchange the code with a team member without checking the code in.

Hope this helps.

Answer 2

I don't trust my local hard drive not to crash overnight. Shelving = backup, for me personally.

I've also been on teams that use the shelving feature for exploratory/proof of concept coding that might span several days. It let's you see how something might fit into the software without really committing to it too much.

Answer 3

Amongst other uses that are already posted (backup, sharing, etc.): we use it for code reviews.

1. Dev shelves code that you want to check in
2. Dev creates code review with shelveset name
3. Reviewer unshelves code into latest, reviews/runs
4. Reviewer approves code review
5. Dev unshelves code into latest
6. Dev checks in

So when I fix a bug or a feature or whatnot, I shelve it and create a code review for my lead, then I undo pending changes on the sln and work on the next task until the review comes back. Then I shelve what I'm working on, unshelve my reviewed code (change whatever I need to depending on my lead's comments) and check in. I then unshelve what I was working on and continue.

Once you're used to it, it's a pretty smoothe process.

Answer 4

I don't know about others but sometimes I'm working on a large change that is lower priority and another change comes up that is higher priority and so I shelve my work and do whatever needs done first. Also as Fish pointed out shelving backs up your code. Nothing worse than losing all your work especially right before it is done.

Answer 5

My team shelves code when they want to share something with another developer without having to check in that code (vacation, vetting prototype, building one change set on multiple machines, etc.)

I also have some developers that use it in order to build up a few change sets (usually independent and small) so they can ask one person for multiple code reviews all at the same time.

Answer 6

in our environment,

1. A Developer first get latest version of the SLN within TFS before making any changes.
2. modify code or/add a feature & shelve changes as many times as needed during the day.
3. Perform unit testing
4. when unit testing is done for the changes/or added features by the end of the day, Dev creates a final shelf set by unchecking "preserve pending changes locally" checkbox
5. Dev send an email to Team lead about the final shelf

6. Team lead will review code and if approved will apply the Dev shelf and send a reply email to DEV to test the changes in the Test environment. if code is not approved, Dev will unshelve changes and make more modification go back to step4

7. Dev runs test cases in test Environment and if everything is according to the desired results, then Dev notify the user coordinator or Business analyst for Project as ready for UAT.

8. at this point Dev will see his/her changes in TFS

and cycle begin again from Step 1.

it is good practice for the developer to shelve the changes at the end of the day as a backup. it is also a good practice for developer to get latest SLN changes several times during the day.

communication is important between developers to avoid working on the same module and overwrite each other code.

Answer 7

I think it's a bit more complex and nuanced than the other answers given here, but also that there's a good discussion of it on StackOverflow: https://stackoverflow.com/questions/556981/what-is-shelving-in-tfs-just-a-soft-checkin-so-others-can-see-code

Yes, it's about being able to check things in and go home, but it's also so that you can set down new work at a point where that work isn't ready to be committed, so that you can work on other things in the same solution. The example for this is having to set down new development in order to address a bug. You can shelve the new development, pick up the released version, address the bug, and then return to your new development.

Answer 8

I have been using shelving the same way I use stashing in Git. I need to put my current work aside in order to fix something else first. Once this fix has been made, I can resume where I was.

This fix could be a critical bug fix (I say 'could be', because I have never actually had to, but it would be a valid reason). Rather, I have mostly done this because I identified a refactoring that should be made. I would never work on both the refactoring, and the new feature on the same time, and check them in in the same changeset. I would always first implement the refactoring, check that in, and then work on the feature/functionality, and then check that in.

In regards to a lot of the other answers about using shelves as a backup measure, I wouldn't bother. In the 20+ years I have owned computers, I have only experience a hard disk crash once, and that was because I pulled it out of the computer while it was still turned on (and I still managed to salvage the data by replacing the print board). So if this unlikely event really should happen, how much work would you have to recreate? If it is a significant amount, then I would say that your change-sets are too large.

So even though there is nothing wrong with creating a shelve for backup purposes, I just wouldn't bother.