Architecture Models … to branch or not to branch

  • Article

In  Branching and Team Project Guidance … looking for “your” input! we started a discussion on the new branching scenarios and what the rangers are planning to add to the existing Branching Guidance (https://tfsbranchingguideiii.codeplex.com) and the Architecture Tooling Guidance (https://vsarchitectureguide.codeplex.com) in the next refresh.

This weekend I did some explorations and testing in terms of the “Architecture tooling and modelling branching scenario” topic, to evaluate and confirm some of our discussions on architecture models, UML diagrams and the feasibility of branching and merging these artefacts.

My “simple” test:

  1. Create a main branch
  2. Drop a small solution with an empty UML Class diagram model project in main.
  3. Branch main to Dev1 and Dev 2, simulating two development teams.
  4. Do the unthinkable and add classes to the empty UML Class diagram model in both the Dev1 and Dev2 branch, using same class names and different operations.
  5. Merge Dev1 back to main … everyone still happy.
  6. Merge Dev2 back to main … pfffff … Houston we have a challenge.

I am probably lining myself up for a heated debate with the XML evangelists and enthusiasts, because my conclusion is to avoid branching and merging with models at all cost at this stage. The current tooling forces us into a challenging corner where we have to merge XML files, understand the related model file contents, contend with files that interleave other models, and cross link GUIDs and other metadata as shown in the following merge panes:

The challenging environment, however, seems to be a perfect out-of-band-Rangers solution opportunity :)

What are your thoughts and should we discourage development teams from branching and merging models?