I wrote about Hot Fixes being inclusive of previous hot fixes. Someone questioned this and so I went back to Simon's blog and checked his source. He's a SQL Server MVP (and a great guy, I got to meet him at the Summit last year) and he got it from the MVP Summit.

I think it's controversial, mostly becuase I and many others, assumed that each hot fix was independent, but if you stop and think about it, as I have been doing, it makes sense. No one wants to maintain multiple code bases. It's hard and in vastly increases the chances for problems. Plus merges might be the least favorite thing for people to do, even less liked than bug fixes.

Think about it, you have SQL Server, this huge, multi-million lines of code software product. Suppose you have modules 1-5 to keep things simple. If there's a problem in module 2, you branch the code and start working on a Hot Fix. Now you also have work going on for the next service pack in Modules 3 and 4. You finish this patch and you have this:

Main branch               Hot Fix 1 Branch
  - Module 1                   - Module 1
  - Module 2                   - Module 2 patched

  - Module 3 (updated)   - Module 3
  - Module 4 (updated)   - Module 1
  - Module 5                   - Module 1

We have two branches and they can easily be merged at this point. Now suppose we're still working and someone finds a bug in Module 3. Now what do you do? You can branch again and get this

Main branch               Hot Fix 1 Branch              Hot Fix 1 Branch
  - Module 1                   - Module 1                   - Module 1
  - Module 2                   - Module 2 patched      - Module 2

  - Module 3 (updated)   - Module 3                   - Module 3 patch in progress

  - Module 4 (updated)   - Module 1                   - Module 4
  - Module 5                   - Module 1                   - Module 5

or work with your old branch

Main branch               Hot Fix 1 Branch
  - Module 1                   - Module 1
  - Module 2                   - Module 2 patched

  - Module 3 (updated)   - Module 3 patch in progress

  - Module 4 (updated)   - Module 1

  - Module 5                   - Module 1

But in either case, you have work to be done in merging. If this continues with 5 hot fixes, then the first scenario here gives you problems with many merges, 5 in all. And what if you need to make a second patch to Module 2. Not fix the first patch, but a separate problem? Then you'd have two merges in this module. Expand this to the hundreds of modules in SQL Server and you might have an idea of the problems.

The best solution is to perform builds using good code. Which means if you have modules that are works in progress, you ignore the current version and build with the last known good version. Which is what happens. So the best idea is something like this:

Main branch              
  - Module 1              
  - Module 2 (hot fix in progress)              

  - Module 3
  - Module 4
  - Module 5

then

Main branch              

  - Module 1              

  - Module 2 (patched)              

  - Module 3 (being updated, build with last known good for hot fix)

  - Module 4 (being updated, build with last known good for hot fix)

  - Module 5

then we find a problem with module 3

Main branch              

  - Module 1              

  - Module 2 (patched)              

  - Module 3 (being updated, work on new hot fix with current version. Maybe delay unti update is finished or do both at once)

  - Module 4 (being updated, build with last known good for hot fix)

  - Module 5

etc. It's still dicey when you have a problem with an area and a separate hot fix, but you're Microsoft. Throw a few more people at it to get it done quicker. Even comment out changes in code that are work in progress.