Project Modeling

Question

At our company, we started using VS 2010 to model our systems in so-called simulation projects. They are stored under source control of TFS2010.

All this is good for one user, but as soon as we presented this tool for our entire architecture team, we faced a serious problem: it does very poorly with several users! Let me run you in a simple scenario.

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

As I understand it, the problem is that the architecture project is based on several xml files and, in particular, on one important huge xml fragment called ModelDefinition / Architecure.uml. It contains a lot of knowledge about diagrams in a modeling project. When several people make several changes to this file at the same time, tools (TFS, VS) do not process the required merge automatically, and we still have huge concurrency problems.

So, in my scenario, because Architect.uml, which architect 1 registered, knows nothing about the elements added by architect 2, these elements are overwritten or otherwise destroyed.

We want to avoid dividing the project into several smaller ones, because this will mean that we will have to redefine our modeling components (classes, participants, use cases, components, etc.) several times. Using one solution, we can identify such elements in one place and reuse them in every other diagram.

So, our current “solution” should work using exclusive checks. Therefore, only one architect can work at a time!

I was hoping that someone came up with a better solution for this, which allows us to work more efficiently.

Answer 1

Try to divide and win: is it possible that each architect works on his own branch, and then everything merges into the "Highway"?
Conflicts must occur during these mergers.

---

EDIT
You can use a tool specific to XML, for example, presented here .
In doing so, you should follow the branching approach for each architect, BUT instead of using the one-step TFS merge, you could:

• Compare directories between your branch folder and the trunk folder. Each file found is the subject of the next merge.
• Drain each found file into the "branch" folder using one of the tools presented in the article. I used Altova DiffDog , this is very good - but it brings a high gain.
• Make sure everything is in order, and then lock the "branch".
• Now merge with the TFS-merge in the 'trunk', which should now be a trivial merge.