Relationship between versioned model and EAP file

[CleverCoder]

Continuing the adventure into integrating EA into our source tree...

Suppose we have 5 developers working on a solution that has been linked to an EAP project.  Those developers want to all be able to add and edit diagrams in a package in the EA project...

Can someone explain the relationships between the versioned model elements and what purpose the EAP file serves? It seems binary, which raises a red flag for concurrent work...  

Can we all work on a solution against the same or different diagrams with the integrated version control support?  .. Are there best practices for concurrent development? (Like maybe having a package for each project that can be locked for editing)...

So I guess I'm looking for some best practice / practical advice for large scale application develompent with EA and subversion using the MDG link integration..

Thanks!
-Sean

PS. I'd love to email Support... but waiting a day for an answer is depressing.. (I'm in the US)

[thomaskilian]

The EAP is a M$ Access Database to perform the queries. Version files are exports in XMI format. Search the forum for related topics and read the resources on Sparx' site.

[CleverCoder]

Thanks for tips!... Altough I was hoping for a more precise explanation. I have read the integrated documentation... I haven't scoured the forums (very time consuming).

And what queries?  I'm creating diagrams... linked with code. I don't remember reading about queries yet. Maybe I'm just too naive, but it seems that there is a lot to the product that new users might struggle with. Maybe this is a gap in the documentation (which is what it feels like).

If there is online documentation, where is it? A quick search didn't help me find much about the MDG integration / EAP files / SVN integration....  I would expect it to be in the installed documentation.

I'll look further next week when I have more time to devote to it.. Honestly, it shouldn't be that hard to explain (IMHO)..
I do appreciate any help!

Thanks,
-Sean

[danm]

"very time consuming"

Should we do your job for you? Sorry I'm not trying to be snotty, but you have to gain experience in doing this kind of work. It's not a simple answer such as 'yea just split the model up five ways and it'll all work'

Here is a starting point, but you have to think this through, do tests, and decide what works for your project

• A corollary on Conway's Law - your model structure represents your organizational structure and vice versa. Don't make one monolithic model if you have a team spread across the world.
  
• Your model structure should reflect your architecture. If you have a microkernel and plugins, maybe a model per each of those with tight dependency management.
  
• Your model structure should reflect your VC system. In VS, maybe a project per model.
  
• Above all be careful about dependency management across models.
  

You will have to spend some hard time figuring this out and gaining experience.

[Aaron B]

Sean,

On the technical side of things at least - there are several ways to deploy a version controlled model for collaborative development.  One method for example is to have each user maintain their own local private eap file and retrieve the packages they need from Version Control (Something like the "Shared Packages" usage mentioned in the EA Deployment whitepaper).

Some suggested reading - You might find some useful information in the following White Papers:
EA Deployment
Version Control

[CleverCoder]

Fair enough. I will eventually spend plenty of time digging... testing... experimenting... figuring out what makes it all tick. Honestly, my urgency comes from the powers that be that have indicated they have the desire to start "using the version control features" of EA.  We have 1Mil+ lines of code under version control, spread across multiple VS solutions.  I can tell that EA is a mature product with quite a few users that really know their way around.  Honestly, I feel a bit surprised at the responses. I'm glad you already know about how version control integration works. And I'm sorry to say, searching forums is a cop out for missing documentation. I love forums and will use them as much as the next person, but when first getting my feet wet, I would like to have thorough documentation.

So... doing my job. I have the simple question of "How does the EA project file that is part of a Visual Studio solution relate to, and is managed by, version control?"

I found "Version Control" in the docs. Let's see... 'version control setup'.. 'use version control'... 'Version Control Reference'..
"Version Control Setup" - Nothing useful there. It's already setup. This part works fine.
"Use Version Control" - Ahh! Hope!.. Nah.. talks about packages exclusively.. Lots of good info for managing packages, but it doesn't answer my questions..
"Version Control Reference" - Good stuff.. still... nothing about working with MDG link or the EAP file.

So... now I'm thinking... "maybe there is some MDG / Version Control docs"...
Well.. looky there. I see no installed documentation.. great. Nothing in Visual Studio Combined help... nothing in the start menu with EA.. but wait!
Yeah! A CHM file in the program folder. Eureeka! (maybe)
..
after reading the entire help file... I found nothing about version control.

Okay.. so there are 'resources on Sparxs' site'.. let's see if I can find them....
I looked. I found a resources page with a bunch of stuff. Nothing that helped.

I challenge you to find a resource thats not a forum thread that explains how to use version control integration with MDG link.. I'll be going the forum route next week.

yeah.. it did sound a wee bit snotty.. but I'm pretty good at digging up this kinda stuff... and this seems like a genuinely blaring gap in documentation.

Cheers!
-Sean

[gpc]

Hi Sean,

The documentation is pretty much there, but it's also useful to get a feel for what people really do (i.e. information available only in the forum).
I'm currently working on a small project involving primarily two people located at opposite ends of the globe. I use perforce as the version control system and a private model - it was difficult setting up a shared space on a private server and also slowed my machine down emmensely. I have seperated the packages so that we should not need to access the same packages at the same time, but I still view the repository before checking out just to make sure that my package isn't already checked out (it would be a nightmare to try and merge conflicting changes!).
Not ideal, but it works.
Just one example of usage, perhaps others could share/have shared their experiences.
HTH.

Gary