Modeling project woes

Question

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.

Answer 1

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.