TFS2010 Ветвление для частых выпусков и неограниченного обслуживания

У меня возникли проблемы с поиском хорошей стратегии ветвления, которая позволяет легко объединять и отслеживать наборы изменений в нашей среде.

Краткое описание управления выпусками выглядит следующим образом:

У нас есть несколько коммерческих продуктов как часть решения. Неизменяемые внешние факторы приводят к тому, что нам приходится поддерживать несколько версий программного обеспечения на неопределенный срок . Релизы происходят слишком часто и обычно в ответ на список улучшений или дефектов и по ОЧЕНЬ агрессивным графикам. Релизы, содержащие только исправления, обычно представляют собой точечные релизы, поддерживаемые в родительской ветви релиза. Релизы с новой функциональностью обычно становятся новой версией / веткой.

Дерево системы управления версиями выглядит так:

- 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

Dev, очевидно, является нашей ветвью разработки и не ожидается, что она будет стабильной. Изменения разработчика, прошедшие рецензирование, переводятся в основной пакет, который я считаю стабильным, но все же разрабатываемым кодом.По мере того, как мы добавляем новые функции в магистраль (обычно в ответ на проект заказчика), мы в конечном итоге приближаемся к выпуску, и я перехожу из магистрали в ветку, подобную «Product ABC 2.0» выше.

Кошмар развивается, когда мы начинаем исправлять дефекты в ветке выпуска. Мы хотим объединить их обратно в ствол, но сначала он должен перейти в ветку dev - однако, поскольку ветка была создана из ствола, это невозможно, если мы не выполним безосновательное слияние обратно в dev. Точно так же, если мы вносим изменения в dev и перемещаем их в ствол и хотим снова объединить их в ветку продукта, это невозможно без безосновательного слияния.

Это просто кажется настолько запутанным планом ветвления, что я убежден, что он полностью неправильный или что нет хорошего способа разветвления с нашей моделью и тем, сколько выпусков мы делаем и поддерживаем годами для разных клиентов.

Руководство MS (даже расширенный расширенный план), похоже, основано на более простых сценариях выпуска. Есть ли что-нибудь, что мне здесь не хватает, что могло бы вернуть немного здравомыслия?