Team Foundation Server (TFS), later evolving into Azure DevOps Server, offers a robust version control system. A crucial feature within this system is shelving, providing developers with a powerful mechanism for temporarily setting aside changes without checking them into the main codebase. Understanding shelving is essential for effective collaboration and efficient code management within a TFS environment. This article delves into the intricacies of shelving in TFS, exploring its benefits, usage, and best practices.

What is Shelving in TFS?

Shelving allows developers to store pending changes on the server without committing them to the main branch. Think of it as a personal, temporary storage area for your code. This is invaluable when you need to interrupt your work on a task but aren’t ready to check in incomplete code. It’s a safe haven for your work-in-progress, preventing it from interfering with other team members or destabilizing the main codeline.

Shelving captures all modifications, including file additions, deletions, and edits. It also stores associated check-in comments, providing context for the shelved changes. This comprehensive snapshot ensures that your work is preserved exactly as you left it, ready to be resumed whenever needed. Unlike a local commit, shelving makes your changes accessible to other team members, fostering collaboration and code review.

Shelving differs significantly from a check-in. Check-ins integrate changes directly into the source control branch, making them immediately available to everyone. Shelving, on the other hand, keeps changes isolated until they are explicitly unshelved and merged into the desired branch. This distinction allows for greater flexibility and control over the integration of code changes.

Why Use Shelving?

The utility of shelving extends to various scenarios. Imagine needing to switch tasks urgently to address a critical bug fix. Shelving allows you to save your current progress without disrupting the main branch. This ensures that the codebase remains stable while you address the urgent issue.

Code reviews also benefit significantly from shelving. By shelving your changes, you can easily share them with colleagues for feedback before merging them into the main branch. This collaborative approach improves code quality and reduces the risk of introducing errors.

Another common use case is interrupted work. If you need to step away from your task unexpectedly, shelving provides a safe way to store your changes, ensuring they are not lost and can be easily retrieved later. This is particularly helpful in protecting against data loss due to unexpected system issues.

How to Shelve and Unshelve Changes in TFS

Shelving changes in TFS is a straightforward process. Within Visual Studio, or your preferred IDE integrated with TFS, right-click on the files you want to shelve and select “Shelve Pending Changes.” Provide a descriptive shelveset name and comment to help identify and understand the shelved changes. This ensures clear communication and efficient retrieval.

1. In Visual Studio, navigate to the Source Control Explorer.
2. Right-click on the files or folders you wish to shelve.
3. Select “Shelve Pending Changes.”
4. Provide a shelveset name and comment.
5. Click “Shelve.”

To retrieve shelved changes, or unshelve them, navigate to the “Pending Changes” window in Visual Studio. In the “Actions” menu, select “Find Shelvesets.” Locate the desired shelveset and click “Unshelve.” This will restore the changes to your workspace, allowing you to continue working where you left off.

Best Practices for Shelving in TFS

To maximize the effectiveness of shelving, consider these best practices. Use descriptive shelveset names and comments to clearly communicate the purpose and content of the shelved changes. This helps in quickly identifying and retrieving the correct shelveset.

Avoid shelving incomplete or broken code unless absolutely necessary. Shelving broken code can hinder collaboration and make it difficult for others to understand the context of the changes. If you must shelve incomplete work, clearly indicate its status in the shelveset comment.

Regularly clean up old shelvesets to avoid clutter and confusion. Shelvesets that are no longer needed should be deleted to keep the repository organized and easy to navigate. This prevents the accumulation of outdated shelvesets that could lead to confusion and wasted time.

• Use descriptive shelveset names.
• Avoid shelving broken code.

For additional insights on version control best practices, see this helpful resource: Version Control Best Practices. Also, check out Microsoft’s official documentation on Shelving and Unshelving and Suspending Your Work and Managing Your Shelvesets for comprehensive information.

Featured Snippet: Shelving in TFS (Team Foundation Server/Azure DevOps Server) allows developers to temporarily store pending changes without checking them into the main code branch. It’s essential for interrupting work, code reviews, and collaboration.

[Infographic Placeholder: Illustrating the Shelving Process]

FAQs

Q: Can I delete a shelveset?

A: Yes, you can delete shelvesets that are no longer needed. This helps keep the TFS repository clean and organized.

Q: How long are shelvesets stored in TFS?

A: Shelvesets are typically retained until manually deleted. However, server administrators may configure retention policies.

Shelving is a vital tool in the TFS (and Azure DevOps Server) ecosystem. Mastering its usage empowers development teams to manage their code efficiently, collaborate effectively, and maintain a stable codebase. By understanding the principles and best practices outlined in this article, developers can leverage shelving to streamline their workflow and enhance code quality. Explore the resources mentioned above to delve deeper into specific aspects of shelving and version control. Start implementing these practices today to unlock the full potential of shelving in your TFS environment and improve your team’s development process.

• Start using shelving today!
• Learn more about branching strategies.

Question & Answer :
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?

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?