Presenting “Visualizing Change Using TFS 2010” @ the Raleigh Code Camp (RDUCC)
Last week I had the honor to present a subset of the features we developed for version control in TFS 2010 at RDUCC. In this presentation I introduced the audience to branches and what advantages we get by defining a branching model and adhering to it. I then used 2 common problematic scenarios that usually happen when you work in different branches and I illustrated how the new history, annotate engine and branch visualization help solve these problems. Here is a summary of my presentation:
1. Working With Branches
A branch is a self-contained snapshot of the sources. In a typical small project “MyDemoProject” for example, we will have a “Main” branch that will always have our latest stable bits, of that we will have “Dev” branch where we do all of our un-stablizing development activities, we will only merge changes made in the “Dev” branch to “Main” when a certain iteration is complete. When it is time to release our product, we will create a release branch where we can branch “Main” to a “Release”, the “Release” branch is where we do the final testing and release activities.
Some teams will have a different structure with a “Dev” branch, “Staging” branch and a branch for every release.
Why do we typically work in branches?
We need branches for a lot of different reasons, I will only list 2 of them here:
- Branches provide team isolation : e.g. A team of 10 developers is building an application. There are two feature teams, each led by a development lead. Each team want to work independently from the other team without having to worry about the changes the other team is doing. They only need to integrate the common areas from time to time. Branching is the answer.
- Branches helps you easily provide patches to maintain your release: e.g. A development team has just gone live with the first release of a Web site. The development team has started working on the next version of the site, but a critical bug is found by an important customer on the live site instance. The fix can easily be made on the release branch and published to the customer.
For more information about what Microsoft’s branching recommendation you can refer to the Team Foundation Server Branching Guidance.
2. Scenario # 1 : Figuring out a source of a change
Typically during release times you will get an email that will sound something like this. “Using Beta2 build#1013, I cannot add do such and such” and a P0 bug is opened. The developer will jump in, attach the debugger to figure out the problem. And the answer is that “This happened because of a change that was made in ‘Program.cs’ that came from a recent merge to the Beta2 branch”. And the key question here is “WHO DID THIS CHANGE AND WHY WAS IT MADE?”
To figure out the source of this change, you will typically execute “tf history” or history from inside visual studio. Unfortunately, the history view in Visual Studio and TFS 2008 will only show you the merge changeset but not a break down of what the merge brings. To find what you are looking for, you will have to figure out which branch was merged into your Beta2 branch. You will then need to re-execute history there to figure out the information you are looking for.
In Visual Studio 2010, the history dialog was re-designed to perform these tasks for you. In Dev10 you will be able to drill down any merge or branch operation to see the actual changesets that made it with this merge. Further, history dialog will also show you the path of the files where these changes were made. This is a snap shot of the new history dialog. As you can see the history control is now a tree view to enable you to drill down a merge as deep as needed.
Instead of the History Dialog, the developer could have chosen to use annotate. Using VS/TFS 2008 annotate will only show the merge edit changeset and will not drill down further too. As you can see here both fixes were attributed to the merge changeset 29. Although the main experience of the feature has not changed much, but for Dev10 Annotate was enhanced to automatically drill down any merge changeset to show you the real changeset where the change actually happened. As you can see here, the change sets that contain the edits are the ones displayed.
|
The first scenario was addressed by the new History dialog and the annotate engine enhancement.
3. Scenario # 2 : Figuring out whether your change was merged in Branch X
One other typical scenario that happens will be when you are about to release and conducting the final testing phase on your release branch, you find a bug in that branch that you are 100% sure you already fixed. And you wonder, was that fix made before the release branch was created or after? What if you actually want to know which branches in your project have the fix and which don’t. If you have a couple of branches that would be easy. But what if you have tens of active branches.
To address this issue, TFS 2010 introduced the concept of first class “Branches”. A first class Branch is a container of files and folders with a tag that indicates that this is the root of a branch. The Branch holds some meta data about the branch such as the owner, description and information about its relationship with other branches. With first class branches comes a whole new set of features:
- Visualizing Branch Hierarchy
- Tracking Changesets
- Tracking WorkItems
VS/TFS 2010 provides you with the capability to actually visualize the relationship between the branches in a hierarchy view just by right clicking on any branch and invoking “Show branch hierarchy”.
To address the problem where the developer wonders if his fix made it to the target branch or not, the developer can easily query the history of the file that has the fix and from the history window invoke a “track changeset” request. The track changeset window will show you whether the fix was merged into the target branch or not and if it was merged it will show you the changeset of the actual merge. The developer will “VISUALIZE the CHANGE”.
The developer also has two views to chose from. The Hierarchical view to see the change in relationship to the branch hierarchy. Or the time line view to see how the change actually propagated by time.
In conclusion, VS/TFS 2010 includes a lot of enhancements to version control to enrich the developer experience when working in different branches. During the presentation I had a lot of questions from the audience about other upcoming features in VS/TFS 2010. I will post a summary response to these questions in an upcoming post.