Using EA with Subversion and multiple developers

[Mea Culpa]

Hello All,
I've trawled the forum and have managed to find the odd document on how to use SVN with EA but I'm still confused.  Here's what I'm trying to do:

I'll have multiple developers working on the same model. The model is in version controlled with Subversion (SVN).  Different parts of the model are controlled as separate files and these are also version controlled in SVN.

I am used to working with SVN and other UML tools.  In order to prevent multiple users modifying the same part of the model at the same time each controlled unit has the svn:needs-lock property set on it.  To work on a particular part of the model an engineer first acquires an exclusive lock for that part of the model. He makes his changes and then commits his work to SVN releasing the lock at the same time.

Having tried this approach with EA we fall at the first hurdle.  EA complains if the '.eap' file is read only and doesn't allow the model to be opened. Obviously if every engineer needs to lock the topmost part of the model to work on it then concurrent development doesn't exist.
How are other people using SVN with EA? What am I missing?

Any help appreciated,
Regards,
M

[Frank Horn]

There are two documents:

http://www.sparxsystems.com/WhitePapers/Version_Control.pdf
http://www.sparxsystems.com/downloads/whitepapers/EA_Deployment.pdf

Anyway, when I first read them I was still confused, and we had to experiment a lot to learn how we could organize our models.

We use private models with the "Save nested ... to stubs" option. When a new project starts, I put on my admin hat, create a new eap file, and in it a top package "xy project root". I put this package under version control, keep it checked out, and add subpackages like "Requirements model", "Component model" and such, each of which is put under version control as well. Then I check it all in and put off my admin hat.

Now all developers can create a local eap file, import (via the get package menu) the "xy project root" package and perform "get all latest" on it to fill the stubs. Afterwards they can check out whichever model they need to work on and check it in again. The root package only has to be checked out when a new branch is added, or an overall report definition or something.

[Mea Culpa]

Hi Frank,
I can see how your approach works.  If there are no other suggestions on how to achieve what we want to do then we'll adopt it.  It seems odd to me though that you're using private models when EA is supposed to support shared ones.
Many thanks,
M

[Frank Horn]

We considered shared models as well but decided to use private ones.

With shared models there is no nesting of controlled packages because "get all latest" is disabled so you cannot, by mistake, overwrite your changes with the changes someone else has made at the same time. On the other hand there would be no need for check out, cause a shared model (i.e. an eap file, which is actually an MS Access database, on a network drive) supports concurrent access. So you can see immediately what changes others have written to the model.

The reason we decided to use private models was that for shared models only the leaf packages would be under version control, but the overall structure of the project model would not. Unless one puts the shared eap file it under version control as well, but then all the packages would be checked in redundantly.

If you have models on which several developers need to work concurrently, you better go for shared models. If you can split your model into packages which can mostly be edited exclusively than I think private models with nested controlled packages offer more flexibility, since each developer can build an individual eap file with the packages needed. There could even be different controlled "project root" packages for a project, e.g. one with only requirements, components and deployment for someone who has to build a setup, one with only components and classes for one who has to implement things, and so on.

[Mea Culpa]

Frank,
Thanks for the help, it's very much appreciated as this is confusing.  Are you saying then that you do not commit the EAP file into SVN and that each engineer has their own local EAP file? I guess we must have something setup incorrectly because if I checkout a package (say package-X) and modify it then then only file that seems to be chnaged on the filesystem is the EAP file? I expected the package-X.xml to be modified.
M

[Frank Horn]

Well, yes, in our environment the eap file is just a local thing and nothing to do with version control.

Say you have a branch in your repository "Project xy/Models". You check it out to a local folder, then create an eap file somewhere, add a version control ID pointing to your local working copy (where the xml files have been checked out), and get the root package from there. Check out one of the packages from EA's package control context menu, edit it, and check it in again from EA. Then EA will export to the xml file in the local working copy and check it in to version control.

The xml file is up to date then, of course, but you can see in the version control log who has checked it in.

As long as you have not checked in from EA, the changes you've made are only stored in the local eap file. So this private model strategy is allright if your usual scenario is to make small changes and check them in immediately. When you rather work on a model for days on end then maybe you'd better use a shared model on a network drive which is subject to backup every night.

There's a lot more to say about all this, and there have been many discussions in this forum. Maybe later today, when the Americans join us, or tonight, when Australia wakes up, we'll have some comments from the old hands.

[Mea Culpa]

Well, we have EA working elegantly.  The project EAP file is stored on a network drive and is not version controlled.  The project is setup as a shared project with the "Save nested version control packages to stubs only" checked.  Elements within the model are controlled in SVN via the "Package Control | Configure" menu.

I've yet to find clear documentation on how to setup EA with SVN and so perhaps Sparx should revisit this?  Many thanks to those that helped.
M

[Eve]

Have you looked at the first link posted?  http://www.sparxsystems.com/WhitePapers/Version_Control.pdf

This goes into some detail about how to set up subversion.

[Mea Culpa]

Thanks Simon,
Yes, I read that and I found it confusing, perhaps it's me? There are a couple of points I'd make:
a. The document states it's been written prior to EA6 which was the 1st product with SVN support - this didn't instill confidence.
b. The section on SVN talks about how to setup SVN, server and client.  I know how to do this.  What wasn't clear was how the EAP file fits into the picture.  Configuring EA for use with SVN is actually easy but the documentation isn't clear IMO.
Regards,
M

[RoyC]

Was the Help of any use?

http://www.sparxsystems.com.au/EAUserGuide/index.html?subversioncontrol.htm

This, too, describes how you should set up SVN, but the second-to-last topic in the section describes how to identify SVN as your EA version control repository. Please let us know what could be improved.

[Mea Culpa]

Our confusion arose from the way in which the EAP file is used.  The natural instinct is to place this under version control along with the individual XML files.  If you do this then EA doesn't work with SVN.

It seems that the model is stored within the EAP file and as users check-out/check-in controlled packages the EAP file imports/exports data to the separate XML files.  It seemed odd to me that I could load a model, checkout a package, modify it and save it and still the controlled XML file was shown as unchanged in SVN.  It's only changed when the check-in occurs.

There's nothing wrong with the current help in so far as the setup of SVN is concerned.  It seems to me that something is needed earlier in the help so as to make it absolutely clear as to how EA works with SVN because it's not obvious.

Hope this helps.
M

[Krzysztof Swiatkowski]

I think your confusion comes from different understanding of checkout in EA and in SVN .

Developers using SVN and CVS are used to optimistic locking with merge, while those using SourceSafe are used to pessimistic locking.

So in SVN you basicaly never checkout (besides in the beginning) and you can instantly work on any file and when you're done you only commit (EA Check-in).
In SourceSafe and EA you work in a different way. To do any kind of work you first checkout - so you own the file you want to change - and then you check-in so others can see your changes and work on that file too. In EA it would be very impractical to checkout whole model file because only 1 person could work on a model at any given time - clearly a nonsense. Thats why EA works in a manner similar to SS treating Package == file, because XMI package exports are stored in a repository.

Nice question about version control in EA is how you can manage branching and merging of the branches with EA models? It can be a problem if you maintain the old version while working on a new .
Right now I write changes to both places by hand but it increases the work.

Whole source control differences problem is explained in greater detail in <http://www.ericsink.com/scm/source_control.html>

[Mea Culpa]

I think your confusion comes from different understanding of checkout in EA and in SVN .

Developers using SVN and CVS are used to optimistic locking with merge, while those using SourceSafe are used to pessimistic locking.

So in SVN you basicaly never checkout (besides in the beginning) and you can instantly work on any file and when you're done you only commit (EA Check-in).
In SourceSafe and EA you work in a different way .....

No, I'm perfectly aware of the different paradigms for version control vis-a-vis checkout-edit-checkin (SourceSafe, Clearcase, PVCS, SCCS etc) versus edit-merge-commit (SVN).  As I said in my previous post the confusion arose from the way the EAP file is managed (Please see my previous post).  
Regards,
M

[RoyC]

It seems to me that something is needed earlier in the help so as to make it absolutely clear as to how EA works with SVN because it's not obvious.

We have put a trio of topics in at the start of the Version Control section to provide background information and explanations of VC principles and how VC is applied in team deployment. I hope this helps.

[Guillaume]

Hi

I also got confused in using EA with SVN when I started looking at it. Here is how I use it now:

- set up the EA project and put it to SVN version control
- partition the project entirely in SVN so the SVN repository only stores XML files (no EAP file)
- anyone who needs to access the project from their computer must create a new EAP project, and select the option "this model is private" in the version control settings > this way get all latest is available & since each user works on a different EAP file, there is no conflict.
To import the project, they need to have the XML files already available from their drive (i.e. using TortoiseSVN in the Windows Explorer), and import the main model XML file, followed by a get all latest

Basically it seems to me that Sparx implemented the SVN version control with having in mind that all users share the same EAP project
As long as you don't store the EAP project on SVN and force all users setting up their own EAP project, it ll work ok.

Hope it helps