Architecture Models … to branch or not to branch


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 (http://tfsbranchingguideiii.codeplex.com) and the Architecture Tooling Guidance (http://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?

Comments (2)

  1. Could not disagree more about avoiding XML+ branching/merging. Just cause the default compare tool is poor doesn't mean we should hide away.

    Considering you can easily change the default compare tool to something better easily in the settings this is very minor issue. I personally use WinMerge, which handles this issue well.

  2. How do you see other tools, i.e. WinMerge, make the merging of the model XML data any easier? My real concern is the need to understand the file content of three or more interleaved files and associated models to make a meaningful merge.

    What I am interested in is whether users of the architecture tooling believe that a model merge is a common and needed scenario, in which case we could motivate a Rangers out-of-band solution to create a user-friendly merge tool for the models.

Skip to main content