shared user / version control, simply confused

[StevePinfold]

Hi All

Thanks to the group for all the help that you have given me so far. I am now just confused.

I am using EA 9.2 Coporate version and my aim is for users to be able to share a model + all users to be able to use version control. So far, I have managed to,

1. Share a EA project between 2 users by simply putting the EAP file on a shared drive and 2 users can access the model.

2. Configure EA with svn and add a model to the svn repo, check out a model, make changes, check in the model and see this on the svn server.

So, I have most of the pieces but the bit I don't quite get is how it links all together.

I have read the white paper on EA deployment and I see that there are 2 options which suit my application, Shared model and Duplicate models.

Shared Model

My question is - I can put the packages into version control, but if I put the EAP into version control, who owns this file or do both users have it open.

Duplicate Model.

How do you version control the EAP if they are on seperate machines.

Sorry if i have been a bit dumb on this one bit I am just waiting for that light bulb moment.

Thanks in advance

Steve

[Paul Lotz]

We use the shared model.

This means the .eap file is a shared file (on a network drive) that all users can access.  Do not version control the .eap file!  Note that the .eap file contains global options and which packages are in the file, but it does not contain the details of the packages that are under version control.  Those will be in version controlled package (.xmi) files.

Version control all the packages (.xmi files) within the model.  With the Subversion model, each user will then have a working copy of the .xmi files on his or her machine.  (The "master" files reside on the Subversion server.)  When the user checks out a package, he or she can then modify the package (the working copy of the .xmi file on the local machine).  On a check-in the version control application updates the server files from the working copy of the package (.xmi) file.

[qwerty]

Duplicate model: the VC takes over the synching. When you want to change an element you need to checkout the package. That puts a lock on the VC. Others are locked out (which can be very annoying in certain cases). When changes are done the check in brings it to the VC. Now others may update (get latest) or wait until they have to check out the package themselves. In that moment the local copy is replaced by the newest XMI in the VC.

This variant is quite tricky. And has a couple of pitfalls. We finally switched to a central repository with Require Lock to Edit and an automated nightly snapshot.

q.

[Geert Bellekens]

Steve,

Just to be clear, you don't put the .eap file in version control. Version control uses only the exported xmi files to store the model content, not the actual .eap files.

Geert

[StevePinfold]

Thanks for all the replies, they were very helpful.

I can see that the shared model is the one that I would probably adopt as it seems to be the simpler to adopt, and closest to where I am.

I will try it out further and let you know how I get on.

Thanks again.

Steve

[StevePinfold]

Steve,

Just to be clear, you don't put the .eap file in version control. Version control uses only the exported xmi files to store the model content, not the actual .eap files.

Geert

Does this mean that only the project settings are stored in the EAP file and the actual model is stored in the xmi files?

Thanks

Steve

[Geert Bellekens]

No

Geert

[qwerty]

actually the repos is in sql format for a faster search of the xmi.

q.