This project has moved. For the latest updates, please go here.

Model projects and TFS Source Control

Jun 13, 2011 at 3:41 PM

Is there any guidance on how to use modeling projects maintined under TFS Source Control?

We are finding that whenever more that one developer attempts to work on things such as Sequence Diagrams, there are almost always conflicts at check-in time. The end result is lost work or corrupt sequence diagrams, particularly if you attempt to rename a sequence diagram.

Say we have a model project names "MySystem.Model", we almost always conflict on a file named "MySystem.Model.uml", even if we have seperate "Packages". For example, if you add a new lifeline for a class defined in package "A", it not only checks out and updates the .uml file for package "A", but ALSO for the "MySystem.Model.uml" file resulting on conflicts between developers working on sequence diagrams.

Coordinator
Jun 14, 2011 at 12:28 AM
Edited Jun 14, 2011 at 12:28 AM

There is no published guidance at this stage, but is on the feature list for the next Branching Guidance. We have an article in MSDN Magazine, which discusses this topic and MSDN Article – TFS Branching and Merging Guidance recommends that you basically avoid the merging scenario by structuring your solutions and associated models. Have a peek at the article ad advise if that addresses your questions and/or concerns. If not, your candiod feedback will be invaluable for the next generation of the Branching Guidance.

Jun 14, 2011 at 6:30 PM

I had read this article a while back but had forgotten the aspects of Modeling projects it contains. It does summarize the issues that arise due to the way aspects of a model are spread across multiple files. In my teams case, the scenario isn't merging a branch, but simply the issue of having multiple developers working on the same model project at the same time. For example, more than one developer working in the "S1Dev1" branch. The best we could come up with (since I posted this yesterday) was to move diagrams into separate packages to avoid developers needing to check-out and modify the same .uml file. One issue is that when a sequence diagram is first created, it is added to the "Root" model, and then must be moved to a package using the UML Model Explorer. It would be nice if from within the UML Model Explorer you could right-click and select "Interaction" diagram. It would also be nice to be able to double click in an "Interaction" diagram in the UML Model Explorer in order to view it instead of having to go to the Solution Explorer? Did I by chance overlook something, and both of these are possible?

Jun 15, 2011 at 9:19 PM

Unfortunately this is the case and you did not overlook anything. Splitting up the packages is the only way to overcome editing the same UML files and getting into a merge conflict. What is specially problematic is the diagrams and e.g. the sharing of the model elements cross those diagrams when you work in a team. This is one of the reasons the guidance document contains some tips in getting an appropriate package structure up and running to avoid massive merge issues. 

  • Make sure to have a good UML model structure, so model elements are kept in small version controlled units in the modeling project
  • Enable collaboration

The only way to add the functionality you asked like: " It would also be nice to be able to double click in an "Interaction" diagram in the UML Model Explorer in order to view it instead of having to go to the Solution Explorer" is by installing the modeling feature pack and build this extension yourselves. And I know this sounds like a lame solution, but it is the only option I see at this moment. I have not seen or know any existing extensions like this that would add these shortcuts.

We provided the Architecture team with a lot of feedback on these issues. e.g. also the traceability between diagrams, from use case to implementing sequence diagram etc. Unfortunately I have no Idea at this moment if and how this might be addressed in next SP or release. Sorry I cannot provide more help than that.

Marcel