First, In some ways, the way in which TFS stores files when branching seems similar to your *delta branch* concept. I wrote a blog post on this a while ago (http://blogs.msdn.com/b/billheys/archive/2011/05/05/how-tfs-stores-files-and-calculated-deltas-on-versioned-files.aspx).
In essence, when you make a full child branch (branching from a parent branch), TFS does not redundantly store all of the content in both branches. Essentially the new branch contains meta data but not content for all of the files contained in the branch.
Only when changes are made subsequent to the branch are copies made (or deltas) of the changed files.
Second, I agree that David's Process Rules steps 1.1 and 1.2 appear redundant. I think it would be helpful to step back and draw a picture of the proposed branching structure. I might propose something like this:
For the core product, create a branching structure that consists of a Main, Dev, and Release branches. In this way, the Core product could be released on a different cadence from the individual, specialized customer branch structures.
Since each of the customer releases *starts* with a specific version of the core project, you might consider creating a dependency from each Customer branch plan back to the Core project branch plan. You might consider a Main/Dev/Release structure for each
customer. The Main branch might be a child branch of a branch in the core project. From this Customer-Main branch, you could create a Customer-Dev branch and a Customer-Release branch. Granted this will cause, perhaps 70 sets of branches (perhaps three branches
The structure might look like this:
| Core-Release 1.0
| Core-Release 2.0
| Core Release 2.1
Each Customer would have:
| Customer 001 - Dev
| Customer 001 - Release 1.0
| Customer 001 - Release 1.1
| Customer 001 - Release 2.0
and son on
Key here is understanding the relationship between the Customer branch structures (e.g. Customer 001 - Main) and the Core Branch Structures (e.g. Core - Main)
If you want to ensure that each customer stays in sync with upgrades to the core project, you might consider creating a branching relationship where Core - Main is branched to create each of the 70 Customer - nnn - Main branches.
Any time code for a specific customer wanted to accept updates from the Core code, it would merge Core-Main to Customer-nnn-Main
From there, you would merge updates from Customer-nnn-Main to Customer-nnn-Dev on a frequent (daily) basis. But you would merge Customer-nnn-Dev to Customer-nnn-Main only when you reach a milestone and want to begin stabilizing a new release for the Customer.
Once you stabilize Customer-nnn-Main you would branch it for release to Customer-nnn-Release.
With this branch design, you have a set of main, development and release branches for core and for each customer. The main branch for core is separate from the main branch for each customer.
For each version (of either core or customer), follow the basic guidance (merge daily from main to dev, merge from dev to main when it is ready to ship. Stabilize in Main, Branch main to release. Never check changes into a Main branch. Never merge from Main
to Release after it is created, etc.
Alternatively, you could consider a different relationship between customer and core. You could establish assembly references from Customer-nnn-Main to Core-Release-V1 (or v1.1 or v2.0 etc)
When you want to upgrade a customer from v1 to v2 of Core you simply change the Customer's main branch to point a newer version of Core assemblies.
Hope this helps,
VS ALM Ranger