BUGBUG: poor title : branchmerge

UI Bug: resolving multiple merge conflicts

Richard Berg — Tue, 05 Jun 2007 02:08:00 GMT

Resolving merge conflicts is hard enough already. Which branch is "target," again?

Unfortunately there's a bug in v1 that makes it even harder. If you select multiple conflicts in the main Resolve dialog...

...then you get this abomination:

Yikes! Allow me to translate.

Command line / client API	"Resolve version conflict" dialog	"Resolve selected conflicts" dialog
AcceptMerge	Merge changes for me	Merge changes for me
AcceptYours	Keep changes in target branch	Discard server changes
AcceptTheirs	Copy item from source branch	Undo my local changes

Sorry about this. We knew about it before RTM, but caught it too late in the product cycle to fix it correctly. Adding more intelligence to this dialog was one of the changes we took in Orcas -- and we're still tweaking things, trying to improve usability here & there without breaking anything. (A complete revamp of the workflow will have to wait for Rosario). If you find any more dialogs worthy of WorseThanFailure vilification in Beta 2, please let us know!

edit: just to prove how confusing this is, my chart was wrong...thanks to Chris Sidi for the correction

TFS Branch & Merge whitepaper plus recommended links

Richard Berg — Thu, 22 Mar 2007 06:25:00 GMT

It's finally here! Our first real guidance on branching & merging has been posted, on a Codeplex wiki no less. I reviewed several drafts of the paper, but the real credit goes to Mario for driving our (the product group's) side of the process. Congrats to him, the UE team, and the VSTS Rangers on this milestone.

Definitely watch the recent Channel9 "Branching 101" interview while you're at it. I get asked for branch/merge guidance constantly on the MSDN forums; while there are lots of good resources on the web, the interview & whitepaper above make relevant recommendations much easier, especially for TFS users. If you finish those two and still want more, make CMCrossroad's encyclopedic Streamed Lines your next -- and probably final -- stop.

Next in the pipeline: best practices for Team Projects, headed up by the same Doug Neumann of Channel9 fame. (he doesn't have a blog, so I'm going to embarrass him by linking up his old homepage instead) What substructures can I create within a Team Project? What do the TFS Team Project limits mean for my org? Where do I put shared code? If you finished the branching docs but still had questions like these, that was intentional -- branches and team projects are orthogonal, far moreso than many people think. Stay tuned.

When your feature hits the blogosphere: SCM and the Windows Shutdown crapfest

Richard Berg — Fri, 01 Dec 2006 18:23:06 GMT

Moishe Lettvin has a great blog entry, an inside look at how a Vista feature ate thousands of man-hours on its way to the lowest common denominator. I don't mind the UI myself (and certainly won't justify Joel's histrionics with a link) but it does illustrate several common pitfalls in large-scale software development.

Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes. It should be noted too that the only common ancestor that my team, the shell team, and the kernel team shared was the root.

Well, branch integration was my feature. While my job focused more on finding bugs than architecture, you can't own branching & merging at Microsoft without learning a lot about the broader topic of Source Configuration Management (SCM). So I too feel tied to this debate, albeit for a very different reason.

The comments and trackbacks show lots of people dumbfounded at Vista's SCM practices, and not in a good way. Sorry folks -- there are plenty of things from Vista's ship cycle to complain about, but their branch strategy isn't one of them. Granularity in your source control is important for large teams, and protecting the integrity of the root with intermediate stages is even more important. Feel free to argue that the quality gates were too bureaucratic or the integration schedule too random, but they (finally) got the fundamentals right.

Could the particulars of this situation be improved? Sure. As one commenter noted, active development & testing should've been able to happen closer & closer to the root as the feature matured. Even more clearly, the teamwork between dependent feature groups left something to be desired. Much of that is political. And given everything Moishe described I don't think they could've avoiding RI/FI delays entirely. Still, the leadership should've been more willing to create "interdisciplinary" branches for features that were obviously interwoven. (I'm happy to say DevDiv is pioneering this.)