Back around the Holidays I promised 3 “surveys” but I actually only described 2 of them. I’ve finally gotten around to writing up the 3rd one.
In our next release, we are building a slew of new features designed to make managing branching and merging simpler. Right now I’m focused on features to help you understand what branches you have, how they relate, what merges have happened, what hasn’t yet, etc. Our approach to this problem has been to do a scenario based analysis of the problems people face and build solutions optimized for different scenarios. This is as opposed to trying to build the swiss army knife of branch/merge visualization to try to solve every problem with one solution.
Of course the trick is that we need to make sure that we’ve identified the most important scenarios. Then, of course, we need to design good solutions to those scenarios. In this post, I’ll share with you what we think the top scenarios are and some thoughts on what our solution will look like. I’m very interested in your opinions on both topics. Are the scenarios we’ve identified important to you? Did we get the scenario a bit wrong? Did we miss some very important scenarios? Is the direction we’re headed for solving the solution good?
Scenario 1: I’ve identified a change that I want to understand better. That change came into my branch via a merge. Help me navigate through merges across branches to discover what was the original checkin that made the code changes and why.
The primary hook here is through history. When looking at changes in the history of a file, you can now drill into merges and see what changesets were included in that merge. Some of those change sets may also have been merge changesets and you can continue to drill until you get to the original changeset. Having found the original changeset, you can review it to see the changes, associated work items, checkin notes, user, etc.
In this screen shot we are looking at the history of Main.cs in the “Main” branch. Its history includes changes 7170 and 7150. Changeset 7170 is a merge from the “Dev Branch”. It includes changes 7169, 7168, 7167, 7161. 7167 and 7161 are merges from the 2-TVShows and 1-Movies “Feature” branches respectively. You can continue to trace changes back to original checkins like 7160, 7159 and 7158. You explore change sets, compare them against each other, etc.
Scenario 2: I’ve identified a change that is an important change that needs to make it into all the “appropriate” branches. Show me what branches it has been integrated into, when, and what branches it has not yet been integrated into but probably should be?
In this display we are showing changeset 600 that was originally checked into the VCClient01 branch. It shows the set of relevant branches which branches it was merged into (and what changeset it was integrated in). The timeline at the top gives you an easy indicator of “when” the various changes happened. The yellow color of the Lab26VSTS branch indicates that only parts of the change were merged and the red of the Aftershock branch indicates that the change has not yet been merged into that branch. Again, there would be various drill-ins and operations you can perform on these change sets/branches.
Scenario 3: We seem to have a lot of branches and I don’t really know what is what and how they relate. Let me see all my branches and how they relate. Let me see properties and descriptions of each branch so that I can understand what it is for.
We’re thinking something remotely like this. It would allow you to browse the tree, expanding nodes as you go. You’d be able to double click a branch to see properties of that branch – like a description, owner, etc. This isn’t the exact rendering. It’s actually an alternate view for scenario 2 but we think the scenario 3 UI would look very similar (take away the changeset numbers, color coding, etc).
Scenario 4: I’m thinking of doing a merge from my Dev branch to my Test branch. When was the last merge? How much has changed since then? What key work would be merged over? How big are my conflicts likely to be?
We don’t currently have a design or prototype of this.
OK, that’s the 4 scenarios we’ve identified. That doesn’t cover everything we’d like to do in the area of branching & merging but is focused on understanding my branches and merges. We have more features around acting on branches, checkins, etc. But, I would really like to get some feedback on whether or not you think we are headed in the right direction.