Recently I’ve been working with a third party component vendor to resolve a defect. They requested that I create a sample project illustrating the issue and send it to them as a zip archive. Building the project was easy but I didn’t want to send all of the extra stuff that goes along with it. In other words, I wanted a snapshot of the current revision but without the source control bindings. I knew how to do this with Subversion but how did Mercurial handle it?
Mark your calendar for the second meeting of the Indy TFS user group on December 8, 2010. I will be presenting some tips for improving the TFS version control experience. In particular we’ll examine enhancing version control with the TFS Power Tools, replacing the default compare and merge tools, tracking changesets, and integrating some project management features into the version control workflow.
500 East 96th St
Indianapolis, IN 46240
Doors open at 6:00 PM with the meeting starting at 6:30. Pizza and drinks will be provided.
After a lunch-time discussion about branching strategies with TFS I started looking for a good branching guide. The ALM Rangers put together a thorough guide based on lessons learned from real-world deployments. The guide provides general guidance for selecting one of four increasingly complex strategies:
- Basic: Main, development, and release branches
- Standard: Basic + service pack branches
- Advanced: Standard + hot fix branches
- Mature: Single main branch with multiple development, service pack, hot fix, and release branches
Equally important is the discussion about when to create additional development branches:
- Breaking changes: A change in a common library will break other parts of the system until they are updated to reflect the change
- Segregated feature work: A team wants to control when its features are released to other teams
- Next version development: Allows development on the next version to start before the release branch is created
- “Scratch” or Temporary Branches: Prototype work, etc…
If you’re looking for a decent branching strategy guide I recommend starting here. The document is a pretty quick read and well worth the time spent reviewing it but make sure you take some time to review the supplemental materials as well. They have a lot of good information that can help clarify or extend the information in the main guide.
Edit (8/31/2010): The content of this post has been incorporated into my more comprehensive Everyday TFS post. If you’re looking for a general guide to being more productive with TFS on a day-to-day basis you may consider starting there instead.
A nice feature of TFS is that it allows developers to put aside, or shelve, a set of changes without actually committing them. This can be useful when you need to revert some changes so they don’t conflict with another change or when you need to transfer some code to another developer or workstation. Like so many things in TFS the shelve feature can be useful but is hindered by poor tool support. Hopefully the tips presented here can reduce some of the headaches associated with the feature and help you use it to its full potential.
Microsoft made it really easy to create a shelveset. The Shelve dialog is virtually identical to the Check-in dialog so I won’t go into detail about its operation. Shelvesets can be created through any of the following methods:
- File -> Source Control -> Shelve Pending Changes…
- From the Pending Changes window (View -> Other Windows -> Pending Changes) switch to the Source Files panel and click the Shelve button.
- Right click on a file or folder in Solution Explorer and select Shelve Pending Changes…
- Right click on a file or folder in Source Control Explorer select Shelve Pending Changes…
Although Microsoft made it easy to create shelvesets they really fell short on retrieving them. Unless you’ve been observant when using TFS you’ll probably begin by hunting for the elusive unshelve button. Unlike when creating a shelveset where there are access points in places we use regularly, there are only two places to go (that I know of) for retrieving one and they’re both kind of buried.
- File -> Source Control -> Unshelve Pending Changes…
- From the Pending Changes window (View -> Other Windows -> Pending Changes) switch to the Source Files panel and click the Unshelve button.
The unshelve dialog lists all of the shelvesets created by the user listed in the Owner name field. By default the owner name is set to the current user but replacing the name with another user name will allow finding the shelvesets created by that user. Unfortunately there is no way to search for user names so you’ll have to know the name before opening the dialog.
After locating the desired shelveset you can examine its contents through the details button, delete it, or unshelve it. The unshelve command doesn’t really play nice with files that have local changes. In fact, if you try to unshelve a file that has changed locally you’ll probably get an error dialog talking about a file having an incompatible local change. Luckily there’s a work-around that, like so many other things in TFS, involves TFS Power Tools.
- Open a Visual Studio command-line
- Navigate to the appropriate workspace
- Enter the command tfpt unshelve
- Locate the shelveset to unshelve
- Select the unshelve option – a second dialog box will open listing any conflicts needing resolution
My team is in the process of transitioning from SVN to TFS for version control. One lesson we just learned the hard way was that TFS doesn’t support the concept of nested branching. Early on in our transition I branched an individual folder and things had been going quite smooth until yesterday when we needed to branch the main folder to spin off a side-project and TFS gave me a nice message about the folder already containing a branch. Uh oh…
I spent a few hours grasping at straws trying to get out of this situation. I even tried reverting a couple of changesets with the rollback functionality included in the TFS 2010 Power Tools but nothing seemed to get rid of the old branch. Eventually I stumbled across this MSDN forum post that said the command to change a branch back to a folder is just a matter clicking File -> Source Control -> Branching and Merging -> Convert to Folder in Visual Studio. After selecting that menu item the branch icon changed back to the standard folder icon and I was able to create the new branch. Had this option been available in the context menu I’d have found it right away rather than spinning my wheels but now I know it’s there should I need it again.