Version Control and and shared packages

[armin]

Hi,

It is not possible to share one version controlled package between multiple EA-Models.

Scenario 1:
We have 2 EA-Projects "P1" and "P2". Both of the projects share one package named "common". We put "common" under Version Control (MKS). We open "P1", check out "common" and add a class to a diagram. Now we close "P1" and open "P2". The package "common" which is also used by this project is marked as checked out. If we would execute a checkin on Package "common" now, we would loose any change we made in "P1".

Scenario 2:
We develop a SW-Product and manage sources and EA-Models with Version Control (MKS). When we start with development of a new version of our product, we pin the old Version of all models and sources in MKS. So we can fix bugs in the old Version (e.g. V1) in directory .../Product/V1 and go on with development (V2) in directory .../Product/V2. We also now have a copy of our EA-Project in V1 and V2. The Project in V1 is configured to checkout packages from mks/product/V1 and Project in V2 is configured to checkout packages from mks/product/V2.
If we now checkout a package in V2 it is also marked as checked out in V1 and we can check it in from there. -> FATAL!

Do you have any solutions for this problems? You would help us very much because our modelling process stopped completely due to the discribed problems.

Regards Armin

[peter.zrnko]

I'm not using MKS. We use SVN as Version Control System. But I think the situation is similar.

Regarding scenario 1 - You have discribed the behaviour as it is. To overcome this problem you can have two local copies of Version control repository and configure version control for P1  with one copy and P2 with second (I've heard it's possible with SVN, didn't tried it).

[armin]

Hi Peter,

thank you for your answer. But how do you keep the two copies of your repository in sync?

[peter.zrnko]

I've heard it's possible, didn't tried it. Just now I keep the information where I can edit something (and where not) in my head.

Maybe somebody who used it may be of help to you.

In principle I think it's the job of version control system to keep itself in sync. You can have one central repository and many local repositories. Usualy these local repositories are situated on diferrent workstationes. But you can have two local repositories on one PC.  

[peter.zrnko]

I've tried what I've proposed before and it works (with subversion).

In Project_1 in Version Control Settings set Working copy path to something like:
D:\SVN\Project_1\trunk\models

In Project_2 in Version Control Settings set Working copy path to something like:
D:\SVN\Project_2\trunk\models

I have two local copies of central SVN Repository. One in D:\SVN\Project_1 and second in D:\SVN\Project_2

With this setting I can have a package check-outed in Project_1 and I'm not able to check-out it in Project_2.

You have to think of EA as an editor for files in CVS repository. If a file (package xmi) is check-outed it is in this state regardless of a project where this package is in.

If EA will integrate version controlling in itself it could be better, and all your problems will gone. But EA is a modeling tool not a version controlling tool. It can use version controlling systems on your local workstation.

This has also another consequence. If you have a shared EA project (shared eap file or a project in DBMS) and you check out a package from one PC you can not check in this package from another PC. One can ask why - that package is in the shared file and is the same whether attempting to it from PC1 or PC2? The answer is because EA use a local version controlling system.

[armin]

Typically you are working on complex software systems, if you apply OO based methods on your software development process and use a uml Tool for doing your modelling tasks.

Complex systems fulfil most of the following requirements (beside many others):

1.) It is a common (OO based) procedure to divide the system in particular components with loose coupling. Some of them are domain specific, others are for common purposes.
2.) Developers working in a distributed environment.
3.) There exists more than one version of this software system.
4.) Managing the development of complex system in a complex environment requires the use of a version control system.

I think that any serious UML modelling Tool has to take this points in account. It should support distributed development, management of different versions of one UML Model. Especially it MUST support the use of shared packages across many models. So I can't imagine that the strategic intention of EA is to work only in a "one version - local" environment. For projects working fine in such an environment I don't need a tool but only paper and pencil for modelling.

Regards Armin