Author Topic: Using MDG Link with Version Control (Read 10181 times)

CleverCoder · « **on:** December 17, 2007, 09:23:03 am »

I have come to understand that EA implements version control at the package level through XMI importing/exporting and with predefined 'configurations' that point to a local working copy.

Does anyone know how the EAP file that gets created and associated with a Visual Studio solution interacts with this version control? The file is binary and seems to be just another "solution file". If this shared EAP file contains the contents of the EAP project, and it is binary, how are we supposed to work cuncurrently in EA?

And, for the trigger happy, I HAVE read the documentation and I have searched the forums for answers.

Can anyone help?

-Sean

Martin Terreni · « **Reply #1 on:** December 18, 2007, 01:49:56 am »

I suggest you dont keep the EAP inside VC.
We tried it and it was more trouble then help.
just lets every one have its own loacl EAP file and put all root modules/views/pakcages under VC so you will all see the same project.

CleverCoder · « **Reply #2 on:** December 18, 2007, 06:49:18 am »

That was a thought I had... to not have an EAP file as part of a versioned solution.. But the problem I had with that was that it seemed to counter the purpose of using MDG link! I'll run some tests around that theory today. I'm still anxious to hear Sparx' reply to the matter.

Best regards!
-Sean

Martin Terreni · « **Reply #3 on:** December 18, 2007, 08:41:14 am »

I don't think the MDG integration is about having the whole project file in VC.
The propose it to have one work environment for both design and development or at least to offer a better/more symbiotic connection between the IDE and the design tool.

CleverCoder · « **Reply #4 on:** December 18, 2007, 09:38:03 am »

Thats an interesting possibility. In our case (like many others), we have a rather large codebase that spans multiple VS solutions. This is developed by a team and is kept under version control. We can all go in and make changes, resolving conflicts as we see them.

In comes Enterprise Architect...

The main reason we purchsed MDG Link was to allow us, as a team, the ability to create diagrams and models from our code... and be able to have tight integration with our projects and solutions.

Based on what appears to be happening, the integration portion has no understanding of version control. It creates a single EAP project that is added to the "Solution Files". I have also noticed that this single EAP file is opened (requires r/w) when Visual Studio is opened (or the model window is opened). The EAP file is binary (from what I gather, MS Jet / MS Access format).

What a disappointment. Based on this, any solution that leverages MDG link can't be version controlled.. otherwise, conflicts will abound with respect to the EAP file.

This seems like a MAJOR shortcoming to me. One of the biggest selling points of the EA solution was for us, as a team, to be able to add diagrams and models to our Visual Studio solutions through EA. Because of this limitation, it appears that we have to abandon the use of MDG link..

This will come with a major ramification for myself, as I sold the entire EA solution as a "integrated" solution. If it's not integrated, we don't want it. It's quite simple.

I hope someone has some better news. This is making me quite nervous for an upcoming meeting where I get to explain how our development team can start using EA integrated with Visual Studio. 15 licenses is no laughing matter. This is a serious issue and Sparx tech support STILL hasn't responded to the message I sent yesterday.

Thanks again for any insight..
Cheers!~
-Sean

Martin Terreni · « **Reply #5 on:** December 18, 2007, 09:46:08 am »

I'm implementing this solution in a division with about 700 developer and 100 designers and it never cross my mind to have EAP files in VC.
furthermore we already work in a large application with EA on DB and TFS VC and it works fine and the integration works grate. I also tested and option to have all root nodes and all packages under them in VC,every one having a local EAP file connected to the TFS VC (here I would suggest doing it through SCC with MSSCCI client) and thus every one sees the project exactly the same - it works grate, and we also see the model and can manage and change ti from within VS2005.
I still can't see the reason for having an EAP file inside VC when you can just configure the packages natively in EA and you get XMIs automatically.

CleverCoder · « **Reply #6 on:** December 18, 2007, 10:02:36 am »

I think you have a sensible approach.. and one that I will likely have to sell. Using the method you describe, it sounds like you have no direct integration between Visual Studio and EA.. Is that a fair assumption? .. Which makes me wonder what value the MDG Link integration is buying us.
Martin, it sounds like your environment is a well oiled machine.. do you use the MDG integration? If not, I'm curious how you manage the synchronization between code and the model elements..
It's starting to seem like MDG Link isn't going to help as much as I hoped and we're back to more rudimentary synchronization methods. It would be nice to know what works well.. (And Martin, I sincerely appreciate the input!!!)

Cheers!
-Sean

Martin Terreni · « **Reply #7 on:** December 18, 2007, 11:17:49 am »

Happy to help

The main help of MDG link for us is the fact that the developer can open the design, have it in front of him easily and synch the code from within the IDE, which is his natural environment. Also the synch is done almost "on the fly". you'll see that while changing the signature of a function either it is automatically updtade in design , or with some easy synch from "right clicks" menus. I think these kind of features will work much better for a group if you use a DB instead of EAP, then every one gets the updates "on line".

You can't do EVERY thing in EA from within the IDE, but you can do enough for the developers and the more "technical" designers and for the rest, the more "functional" designers, the design tool is the natural environment any way.

the version control is natively done from within EA (or within the IDE) any way, so it is not an issue. As long as all your packages are under VC - your model is safe.

I'm sure that after a developer gets used to having all in front of him easily, he wont rush to open both EA and VS for his work. For the designers, as I stated, the ROI might much lower. In fact I'm the architect of the system and I almost don't open VS, so for me the integration is something I cna easily give up.

So you see - there isn't one answer to the question "should I use MDG integration", it depend on your role, how intensively each of the users work with the code and with the design.

Hope this answer helps you...

CleverCoder · « **Reply #8 on:** December 19, 2007, 12:57:22 pm »

Wow.. I think I know the problem. We were sold the professional version. It doesn't seem to give is the option of using a database for storing project data.

The minimal correspondence with Sparx never led to the possibility that we needed the Coporate version. This is a major issue.

So... it seems that to truly use MDG link and EA on a team, with version control, the Corporate version is mandatory..

Can anyone back this claim? I think Im' seeing the dim light at the end of the tunnel here. I'm not too excited about explaining that we need to purchase 15 'upgrades' to the corporate version..

«Midnight» · « **Reply #9 on:** December 19, 2007, 01:50:42 pm »

The good news is that the upgrade price is not punitive. It looks like you're talking < 500 USD, so it's not that big a pill to swallow.

Regardless of VC issues, if you were intending to share models via a DBMS back end then you needed the Corporate Edition all along. This is explained in the documentation and wherever the version comparison chart is these days (I haven't needed it for some time).

Perhaps part of the problem is that the evaluation version supports all functions. Even though you need to tell it which 'version' you are running every time you start EA, it is easy to get any function working. That could blur the perception of which edition you need.

Martin Terreni · « **Reply #10 on:** December 19, 2007, 02:28:42 pm »

AFAIK you don't need corporate edition to use the link, that said I do recommend you to use it, you'll see all changes online.

CleverCoder · « **Reply #11 on:** December 20, 2007, 11:27:35 am »

The bottom line is that we use version control today to co-ordinate and allow multiple developers access to work against a rather large code base. This works wonderfully. When I was reading about the different versions of EA, I read that the professional version supported version control. "Superb!", I thought. In addition, there was a tool to allow integrating the EA projects with Visual Studio. (Great!)
So, I tried it all out on my machine. It worked well. The side effect of there existing a project file (EAP file) was one that I didn't think too much about. ALso, my focus was on using the tool, not reading white papers on deployment, etc. Honestly, the DBMS support seemed like an alternative to using versino control from what I was reading out of it. And, because support comes from AU, and it's as responsive as I would have liked, I couldn't get the straight answers I wanted.. so I took a chance.

The real problem I'm seeing comes in the form of vague documentation with respect to the use of MDG Link. It's sold as an integration solution, but it ends there. Not ONCE is the term version control even mentioned in their documentation... And I took it for granted.

Now that I have learned the hard way, I see the grayed out option to connect to a server repository when establishing an MDG link connection. Call me crazy, but I was convinced that the other version control support in EA would replace the need for a DBMS repos. (I'm even wondering how they will take my pitch to have to place EA projects in a database... "oh yeah.. it supports version control... but we have to use a database for some things") Thats a smelly statement in my book.

I have a much clearer understanding of what is required now for using EA with Visual Studio in a team environment. It would be nice to have this explained a little more directly. I've been accused of not reading documentation. I assure you, I have read a lot... but I apparently missed some of the important parts about the DBMS usage and what it's for...

Perhaps they should view it from the eyes of a developer who is used to putting everything under version control.. and ESPECIALLY update the MDG Link docs and requirements to explicitly state that "You MUST use a DBMS repository in order to share your linked EA projects if you use version control!" (This would trump the need for VC in EA then, wouldn't it?... guess I need to continue to RT(many)FM(and white papers)) This can't be too foreign a concept...

I appreciate the folks who helped. I don't appreciate Sparx for lousy US support and lacking MDG documentation.. ALthough the product is good at the actual diagramming and integration piece. I hope someone can benefit from my wasted time and embarassment. Good thing the upgrade price is cheap.

Cheers!
-Sean

CleverCoder · « **Reply #12 on:** December 20, 2007, 11:30:06 am »

Oh yeah.. one more piece of humor. In an email that I sent to their support team starting with "I am having serious problems trying to incorporate the MDG link visual studio integration with our Subversion backed codeabase"..

Nowhere in their reply do they mention MDG Link. It's as if they pretend it doesn't exist!

Eve · « **Reply #13 on:** December 20, 2007, 01:09:52 pm »

Not having seen your email or the reply, I suspect the fact that you're using MDG Link was considered incidental to the fact that you're trying to use EA with your Subversion codebase.

CleverCoder · « **Reply #14 on:** December 20, 2007, 02:44:33 pm »

I just tested the DBMS integration with the COrporate trial. I think it solves our problem. Not ideal (as it's one more dependency we have to maintain), but it works. It's actuall quite cool how two people can work on one diagram..

But yes, I believe that I was taking for granted that our current setup:
Visual Studio + Subversion

Would play nice with
MDG Link + EA (Advertised to 'support' version control)

.. I didn't realize the small hitch surrounding the EAP file and the complexities of 'deployment'. I thought it would play much nicer with our source control repository... especially since MDG link seemed to just create the needed project file, which I think I gave too much credit. My assumption that it was 'merge friendly' was too much. Further testing and reading would have uncovered that.

But, I was spending most of my time testing the product and integration.. not determining if this advertised source control integration would work as we assumed. Lesson learned.

I still feel that the MDG link docs should elaborate on the very VERY common scenario of having your source code under source control. It just seems like a natural match.

Cheers!
-Sean

Sparx Systems Forum

News: