Manage In-Progress Code with TFS Shelvesets
Mickey goes through an example of shelvesets and why they are a nice feature in Team Foundation Server.
One nice feature of Team Foundation Server 2010 Version Control is the ability to shelve your code. This feature is not available in any other version control system currently, and can be very helpful to your development process. In this column I wanted to explain what shelvesets are and how they are used.
As a developer, there may be times when you want to check your code in at the end of the day. However you know your code is in a bad state and could break the nightly build. You want to make sure your code gets put on the Team Foundation Server, to ensure it is backed up that night, but you don't want to break the build. The solution is to shelve your code. When you shelve your code, it takes your code and puts it in a private area on Team Foundation Server. It does not check your code in. Instead, think of this as taking your code, finding a "shelf" or cubby-hole on the server, and storing your code there until you need it again. Then the next day you can unshelve your code and continue working.
Shelving also works well in a code review situation, or when you need help. Let's look at an example to get a better understanding of how shelvesets could help. Figure 1 shows Abu working in Visual Studio 2010.
[Click on image for larger view.]
Abu has created a new function, foo(), but he doesn't remember what the business logic for the function is. He asks his fellow developer, Doris, if she can help. She says she can, and asks Abu to send her the code. In the Pending Changes window, shown in the bottom of Figure 1, Abu clicks the Shelve button to shelve his code. This opens the Shelve window, shown in Figure 2.
Abu only shelves the files he has been working on, in this case Program.cs. He provides the shelveset with a name (Abu – Shelveset – I Don't Know The Business Logic). He also provides a comment for anyone viewing the shelveset to read. As with a regular check-in, he can also associate this shelveset with work items, as shown in Figure 3.
Notice the two checkboxes at the bottom of this window. The first, Preserve pending changes locally, when checked, keeps all changes that Abu has made in his current workspace. If this was unchecked, then the workspace would revert back to its state before Abu started making his changes. The second, Evaluate policies and check-in notes before shelving, when checked, will evaluate the shelveset to ensure no policies are being violated before shelving the code.
To finish shelving this code, Abu clicks the Shelve button.
Doris, Abu's fellow developer, knows the business logic that needs to be added to the function. First, she needs to unshelve Abu's shelveset. In Visual Studio 2010, she selects File | Source Control | Unshelve Pending Changes. This opens the Unshelve window, shown in Figure 4.
By default, this window shows the shelvesets of the logged in user. However, you can view the shelvesets of other users by entering their owner name and clicking Find. Searching on Abu's name shows the shelveset he created earlier. To see details of the shelveset, click the Details button. This opens the Shelveset details window, shown in Figure 5
Notice the two checkboxes on this window. The first, Restore work items and check-in notes, when checked, keeps the values for the work items and comments Abu entered when he created the shelveset. The second, Preserve shelveset on server, when checked, keeps the shelveset on the server. If this box is unchecked, the shelveset will be deleted when it is unshelved. To finish the unshelving process, click the Unshelve button.
Doris proceeds to add the business logic to the application, then checks her code into Team Foundation Server. Doris tells Abu know that she is done making the change.
Abu now needs to retrieve the updated information from Team Foundation Server for that file. If he examines the file in Source Control Explorer, it tells him that he doesn't have the latest version of the file anymore. To retrieve the latest version, Abu right-clicks on the file and selects Get Latest Version. Since the version on the server is different from the version on his local machine, Abu goes through the merge process to merge the changes into his local file. At this point, Abu can continue on with his development.
One thing to remember with shelvesets is they can build up on the Team Foundation Server, taking up space. Your TFS administrator should periodically delete old changesets from Team Foundation Server.
As you have seen, shelvesets facilitate in allowing one developer to help another. Without shelvesets, Abu and Doris would have had to create a new code branch for the code, or Abu would have had to zip up the code and email it to Doris to look at. Shelvesets allowed Abu and Doris to stay in their development environment, while quickly and easily helping each other.
Mickey Gousset spends his days as a principal consultant for Infront Consulting Group. Gousset is lead author of "Professional Application Lifecycle Management with Visual Studio 2012" (Wrox, 2012) and frequents the speaker circuit singing the praises of ALM and DevOps. He also blogs at ALM Rocks!. Gousset is one of the original Team System/ALM MVPs and has held the award since 2005.