Joel writes:

Of all the things broken at Microsoft, the way they use source control on the Windows team is not one of them.

…

When you’re working with source control on a huge team, the best way to organize things is to create branches and sub-branches that correspond to your individual feature teams, down to a high level of granularity. If your tools support it, you can even have private branches for every developer. So they can check in as often as they want, only merging up when they feel that their code is stable. Your QA department owns the “junction points” above each merge. That is, as soon as a developer merges their private branch with their team branch, QA gets to look at it and they only merge it up if it meets their quality bar.

So where does the branching model have issues in Windows?

First, we haven’t gone to a branch(s) per developer so there are semi redundant tools for managing checked in code and tools for managing potential changes not checked in. This causes friction in building and testing such changes. Also a branch implies a path for a change to get some main place or product, and managing the path can be annoying. You get emails of, “The old path is getting shut down, migrate your code to the new path”. At times there is no place to do your work and check it in. Another set of problems come via the quality gates on RIs. Constainsts around how many branches can be built a night and the velocity of change to the overall code base resulting in a need to meet the quality gates quickly and in a automated way. You see, if you take to long to RI, your test results may not be valid anymore becuase the OS has changed enough from other teams.

A lot of this system came as a result of the famed Longhorn Reset and thier was growing pains in such a huge change, so it’ll be intresting to see what system we come up for the next release.