Perhaps we should have been a little clearer in describing the *cost* of creating branches. When you create a new branch (or in this case three new branches: SP, Hotfix, Release), there is not a lot of *overhead* involved. That is to say that creating a
branch does not copy the entire contents of the source branch into the target branch. TFS only stores the differences when changes are made to a file.
The important reason for the order of branches on the release side of the branching structure reflects the purpose of each branch and the direction that changes flow. When you are ready to release a new version of your product (application), you create the
release branch(es) at the same point in time. If you are using the Advanced Branch plan you have 3 branches on the release side. Branch Main -> ServicePack (SP); Branch SP -> Hotfix; and Branch Hotfix -> Release. At this point you would make the release
branch read-only for safekeeping. This branch keeps a *copy* of the code as it was released (without any hotfixes or service packs that might come later). Making a read-only branch is preferred over labels in this context. Labels are modifiable - you can change
the contents of a label after it is defined. Labels would likely not satisfy legal or auditing requirements for a safe-keeping copy of the code as it was released.
It is important to note that changes are never merged *from* the Main branch into the Release branches once they are created. This is primarily becuase, once you create the release branch(es), you free up the Main and Development branches for vNext development.
If you allow changes to be merged from Main (vNext) to Release (vCurrent), you will introduce unwanted changes from vNext into the vCurrent code. Unlike the development side of the branching structure, where changes are merged bidirectionally (forward and
reverse integrations) - in the release side of the branching structure, changes should only be merged from child to parent (Release -> Main ) and not from parent to child (Main -> Release).
It is perfectly acceptable, therefore to make a hotfix in the hotfix branch and merge it from Hotfix -> ServicePack and then from ServicePack to Main. This allows you to bring a bug fix forward into future code releases. If you put the Release branch
(which should be read-only) between Main and ServicePack, it makes the merging (reverse integration) of hot fixes back to main impossible. At the very least you would end up with the Release branch containing the hotfix, when it should be a read-only safekeeping
Back to the cost of branching. The *cost* of branching, therefore is not from creating the branch, but rather from the merging that is required from changes that are made after the branch is created. Merging tends to be labor intensive, particularly when
it comes to resolving merge conflicts. Since we do not recommend bidirectional merging on the release side of the branching structure, this becomes less of an issue. If you create a Servicepack branch and / or hotfix branch that never gets used, that does
not incur a lot of cost - since no changes imply no merging.
Creating the release branches in the order we suggest gives you a post-release mechanism for servicing your code and bringing hotfixes and / or service packs up into the main branch.
VS ALM Ranger.