6

In our company we have started using VS 2010 to model our systems, in so called modeling projects. These are kept under TFS2010 source control.

It's all good for a single user, but as soon as we introduced this tool to our entire architecture team we ran into a major problem: It handles multiple users extremely badly! Let me run you through a simple scenario.

  1. Architect 1 checks out an existing diagram and works on it for a while
  2. Architect 2 adds a new diagram and works on it for a while
  3. Architect 2 checks in his new diagram
  4. Architect 1 checks in his changes to the modeling project
  5. Architect 2 opens his diagram again, only to find that all the elements in it are missing!

As I have understood this, the problem is that the architecture project is based on several xml files, and in particular one important huge chunk of xml called ModelDefinition/Architecure.uml. It contains a lot of knowledge about the diagrams in the modeling project. When multiple people do multiple changes to this file simultaneously, the tools (TFS, VS) does not handle the required merging automatically, and we're left with huge concurrency issues.

So in my scenario, because the Architecture.uml that architect 1 checked in does not know anything about the elements that architect 2 added, these elements are overwritten or otherwise ruined.

We want to avoid splitting the project into several smaller ones, because that would mean that we'd have to re-define our modeling components (classes, actors, use cases, components, etc) multiple times. By using a single solution, we can define such elements in one place, and re-use them in every other diagram.

So, our current 'solution' is to work using exclusive check outs. So only one architect can work at a time!

I was hoping that someone had come up with a better solution to this, which allows us to work more effectively.

havardhu
  • 3,576
  • 2
  • 30
  • 42

1 Answers1

2

Try divide & conquer: Is it possible that each architect works on her personal branch & then everything is merged into a 'Trunk'?
Conflicts should get visible during these merges.

EDIT
You could employ an XML-specific tool, like the ones presented here.
By doing so, you should keep the branching-per-architect approach, BUT instead of using a single-step TFS-merge you could:

  • Perform a directory comparison between your 'branch' folder & your 'trunk' folder. Each found file is a subject to the merge that follows.
  • Merge each found file into your 'branch' folder, using one of the tools presented in the article. I have used Altova DiffDog, it's very good - but comes at a high prize.
  • Check that everything is OK, then commit on 'branch'.
  • Now merge with TFS-merge into 'trunk' which should by now be a trivial merge.
Community
  • 1
  • 1
pantelif
  • 8,524
  • 2
  • 33
  • 48
  • Thanks for replying. It will ensure that no elements are lost without anyone noticing. However, I was hoping to avoid having to manually merge the file, since it's an xml file. It is my experience that the default merge tool that comes with TFS 2010 is poorly equipped to handle xml files, e.g. a moved element might be identified as coflict although it really isn't; it's just swapped position in a non-ordered list. I do apreciate the input though, and I'll take it to my team for concideration. I'll await accepting it for now, to see if anyone else have encountered and solved this nightmare :) – havardhu Nov 08 '11 at 16:01
  • I absolutely agree with your "hoping to avoid having to manually merge XML". Do wait for a better way :) – pantelif Nov 08 '11 at 16:12
  • Thanks for your edit, I believe this might improve the process a bit. Forward integrating the trunk using a proper XML merge tool should be a step in the right direction :) – havardhu Nov 11 '11 at 05:59