Subversion Integration revisited ...

[SwissSteve]

I started to create a test project to validate the SubVersion integration with EA.    I treid to follow the instructions as per the EA help.   I did the following.

1.   Created a Subversion rep structure which under trunk has folders for each model type e.g. UseCaseModel, DataModel, etc.

2.   Created a working directory folder one for each of the above sub folders eg. UseCaseModelWD, DataModelWD etc.

3.   Checked out each of the Subversion sub folders into the associated working directory folder.

4.   Created a EA project with the same model types as above.

5.   Created an EA configuration with a unique id for each of the model types above, e.g. UsecaseModelID etc

6.   From within EA I did an "Add Branch to VC" supplying the config file above for the selected model type and I checked the  "Export as Model Branch".

I now think that EA and Subversion are connected for my project all seems to work fine.  I now have a couple of quesitons.

A.   Is this the correct procedure to follow to enable SubVersion for a project  where there are many developers working on the same models?

B.   Do I need to check in the EAP file for the project so that others can access it?   I read somewhere that this file should be centrally located so that all developers can use it.  Confused by this.

C.   For a new developer to work on this project, what must he do to get access.  My guess is steps 2 to 5 above, what about step 6?

D.   the above seems quite complex and error prone to setup.  Is their a simplier way?

I appreciate any help with this issue

[radle]

Hi SwissSteve,

we used an easier way i think. For example we didnt give ids to each model package but rather for the whole project. I dont know whether it is the right way. And we dont have much experience in it. We just tried it out. But, it seemed to work.

Though we were a little bit disappointed about some points:
- we could not really edit the models parallel. You can work parallel when you switch to Offline and afterwards merge the xml files with an subversion client. I dont know how good this works.
- i dont see a way to update packages (in my working copy) recursively with sub-packages.

Well, here is what we did:

1. Create an empty new folder in repository using a subversion client.
2. Check out a working copy of this empty folder.
3. Start EA.
4. Create a new project in EA and save it in the working copy.
5. From the top package in the tree in EA choose 'Package Control' and 'Version Control Settings'. We gave an id for the whole project.
6. Make 'Add branch to version control' for each package in the tree. EA generates automatically folders where it keeps the xml-files.

For the *.eap file, either it was checked in automatically as we checked in the model packages or we checked it in 'manually' in a subversion client. I dont know any more. But it is in the repository and i think you need it in the repository for some not model related changes. I needed it for template packages (See the help). As i checked in the template package, it wasnt a template package in other developers working copy until i checked in the *.eap and they checked it out.

New developers had to check out the whole in an ordinary subversion client. Then start EA and open the EA-project. EA asks then to complete the version control configuration.

I hope, i could help you,
radle

[Frank Horn]

Steve and radle,

we've setup something similar, and so far it works. But there are shortcomings.

1. We used only one ID for the whole repository. All projects in there, each with a code subfolder and an EA subfolder, an xsl subfolder and what not. This means we can check out or export the complete model and code environment of a specific development stage with one version control client action. The problem there: EA lists all avaible controlled packages in a dialog which cannot be resized, and in a flat list, so we have to browse like idiots to find a package. And since our paths are long (Repository/Projects/Clients/XYClient/WZProject/trunk/EA/Models/Implementation) we don't fully see them in the dialog. A resizable tree view would be welcome there.

2. We put our models into nested controlled packages like

projectXY root package
---referenced projectA
---referenced projectB
---projectXY
------requirements model
------planning model
------implementation model
---------componetX
---------componentY

Everyone can set up a private model of their own, import the project root package and perform "Get all latest" to have the current data.

Problem there: Dependencies have to be one way. One must never draw an association from a controlled package to another one which already has dependencies in the other direction. There needs to be a clear definition which controlled package may reference wich other controlled package, and this has to be enforced (for otherwise "Get all latest" would fail to show all relations in the diagrams).

Since this cannot be enforced technically, someone has to walk around and cut the ears of everyone who has been found guilty of introducing a dependency in a wrong direction.

Like the two of you, I'm not sure at all whether our approach is the right one, but we haven't found a better way so far.