Branching vs. Shelves in TFS

Question

I've always used SVN in my past, and now that we have moved past the initial phase of a project we need to figure out our branching process for future enhancements.

In reading up on this, we see that TFS has Shelving.

How do they compare? What are the big gotcha's on each?

In general, which is preferred and why?

Answer 1

Shelvesets are per-user and differently stored in the source control - it is not possible to merge shelvesets, there's no history etc. The only action possible is unshelving; you cannot even merge files while doing so. So, we only use it as a temporary storage for things that are not finished yet and thus cannot be checked into a branch.

So, you should use branches ;-) maybe a Main branch and different development branches for features & bugfixing.

Answer 2

Shelving and branching are not the same concept.

Branching is taking a code base and "splitting" it off, basically making a copy of it. Development teams can all work on their own branches (for example) and then all changes can then be merged back into an originating branch. Branches can only be merged into a parent branch in TFS.

Shelving allows developers to check code into the source control system into a "shelve". The code is not checked into the main branch. If a build manager or another developer "gets latest", he will not get shelved code by default. The shelve is safely stored in source control like all other code, it is just not in the branch. Other developers can pull shelves down to see the effects. At some point, the changes will be checked into the main branch and will be part of a changeset.

I suggest this book: http://www.amazon.com/Team-Foundation-Server-2008-Action/dp/1933988592/ref=sr_1_1?ie=UTF8&s=books&qid=1263417920&sr=8-1

It has a very simple, yet effective explanation of shelving, merging and various branching models.

Answer 3

Avoid shelves. You'll invariably restore a shelve over a newer version of the files and lose all committed changes. Only use shelves when you start working on a stable branch and realize that the changes needed are bigger than forethought. Then shelve your work, create a branch, and unshelve over it.

Answer 4

Shelving and branching are two totally different things. Shelving allows you to store all your changes into TFS, but they are not actually checked in to any particular branch. Your changes are simply saved under a given name. This is actually very useful because it's a great way to do code reviews. I might have made changes to maybe 10 different files. I'll create a shelveset of those changes with a give name. I'll then ask someone else to review my shelveset. I can then unshelve those changes or delete the shelveset.

Branching is a process whereby you make a complete copy of a trunk of code and give it a name and location. You can then check in/out/merge against the branch of code. This is great when working on the next version of an application. You might create a branch to work on new features.

Here is a good explanation of shelvesets: http://msdn.microsoft.com/en-us/library/ms181403(VS.80).aspx

Answer 5

Shelvesets are collection of pending changes, comments and associated work items.

Scenarios:

• Backup
• Temporarily move changes to work on a different issue
• Remote code reviews
• Buddy builds or coordinate changes

A branch is needed when your development team needs to work on two distinct copies of a project at the same time.

Answer 6

Unshelving on a different branch is not default functionality of TFS.

To unshelve on a different branch you will need to follow instructions from this blogpost

This implies installing TFS2010 Power Tools from VS gallery.

Answer 7

A Branch, is a copy of the main branch. You can use a branch to say try out an idea for doing something. It's great because if something goes wrong, you can discard the original, much like deleting a copy of a file. If things go well, you merge the branch back into the original, say "Main".

A Shelve is analogous to a temp folder. You can use them for a code reviews, or as we do, or if you need to fix something, that way it's in TFS and backed up. You shelve any code that you are working on (giving it a label) and then revert to main. When you are done, you then swap Main for your Shelve, and life continues on without stopping.

Answer 8

If for some reason one cannot commit one's changes, one can shelve the changes. One then has the option to preserve local changes (i.e. keep the shelved copies locally) or revert to the current version locally (and the changes only exist in the shelved copy). If one keeps the changes locally, shelving is a good way to keep a version of one's code on the repository and safe from a local disk crash.

Also, shelving is useful when one has made a lot of changes that are not yet checked in, and one wants to preserve that version before embarking on a "risky and complicated" coding experiment. If experiment turns out badly and one wants to discard it, one can simply unshelve the shelved copy. And if the experiment was successful, one can simply delete the shelfset or let it languish in obscurity.