title: TFS2010 branching for frequent releases and indefinite maintenence
body: <p>I am having trouble figuring out a good branching strategy that allows for easy merges and tracking of change sets in our environment.  </p>
  
  <p>The quick quick summary of the release management goes like this:</p>
  
  <p>We have several commercial products as part of a solution.  Unchangeable external factors result in our having to <strong>maintain multiple versions of the software indefinitely</strong>.  Releases are way too frequent and usually in response to a list of enhancements or defects and on VERY aggressive schedules.  Bugfix-only releases are usually point releases maintained in the parent release branch.  Releases with new functionality usually become a new version/branch.</p>
  
  <p>The source control tree looks like this:</p>
  
  <pre><code>- trunk - dev
    - Product ABC
      - ABC 1.0
        -  ABC 1.0.1 (point release same branch)
      - ABC 2.0
    - Product XYZ
      - XYZ 1.0
      - XYZ 2.0
  </code></pre>
  
  <p>Dev is obviously our development branch and is not expected to be stable.  Dev changes that pass peer review are promoted to the trunk which I like to think of as stable but still development code.  As we add new features to the trunk (usually in response to a customer project) we eventually get close to releasing and I branch off of the trunk into a branch like "Product ABC 2.0" above.</p>
  
  <p>The nightmare develops when we start fixing defects in the release branch.  We want to merge them back into the trunk but it should go into the dev branch first - however since the branch was created from the trunk this isn't possible unless we do a baseless merge back to dev.  Likewise if we make changes in dev and move them into the trunk and want to merge those into a product branch again it isn't possible without a baseless merge.</p>
  
  <p>This just seems to be such a convoluted branching plan that I'm convinced it's totally wrong or that there is no good way to branch with our model and how many releases we do and maintain for years for different customers.</p>
  
  <p>The MS guidance (even the advanced advanced plan) seems to be based on simpler release scenarios.  Is there anything I am missing here that would bring some sanity back?</p>