Use Tagged Versions of a common Project

[Nicola]

Hello,

I have the following situation:
We have a own Framework used by different projects. The Framework contains the source code and the enterprise architect packages.
For revision control we use SVN. With the external function of SVN, we include the Framework into the different projects.
Changes in the framework should not have influence on the other projects, so we include a tagged version of the framework instead the head revision.

I already created an enterprise architect repository for the Framework and added the packages to version control with SVN.
With SVN I created a tag of the Framework (V1.0).
With the "external" function of SVN, this tag is included into the project "example".
For the project "example" I also created an enterprise architect repository and added the packages to version control with SVN (different location and unique id than the Framework). I also imported the enterprise architect packages from the Framework (Package Control -> import a model branch..)
The problem is, because the tag is a copy of the trunk, they use both the same Unique ID (Version Control Settings).
If you check out the Project "example" with the Framework on tag V1.0, and the Framework on trunk, you can only select one Working Copy Path for both check outs of the Framework.
For example, if you change the Framework working copy path in Project "example", it will automatic change the working copy path in the trunk check-out of the Framework and vice versa. This could cause a lot of problems and confusions.

How should I use correctly common enterprise architect packages on different version numbers?
Has anyone experience with common used packages over different projects?


Many Thanks,
Nicola

[Helmut Ortmann]

Hi Nicola,

if I have understood you right you want to check out Packages (Branch of Packages) from different locations (working path).

With EA you can achieve this by defining multiple UNIQUE IDs in Project, Version Control, Version Control Settings. With this you can assemble your project from almost arbitrary

• directories
• Version Control Systems
• Tags
• Branches

Ok, you have to take care that the resulting project is consistent and have no double definitions of objects(Package, Element, Diagram,..).

In some projects we used this to allow partners to work on local repositories and the only connection to the others was the Version Control System.

Once you have understood you will find it a powerful concept. But of course, this also have drawbacks. In the forum you will find quite controversy discussions about EA and Version Control.

Regards,

Helmut

[Nicola]

Hi Helmut,

Thanks for the answer.
I'm not only trying to check out from different locations, but also from different revisions.
Lets say the Framework has the following releases:
Release 1.0, Release 1.1 and head.
Project A and B are using Release 1.0 of the Framework. An update to Release 1.1 should be done in the future.
Project C uses Release 1.1 of the Framework.
And Project D works with the head revision.
Because Release 1.0 and 1.1 are a copy of the trunk, they have the same UNIQUE ID. If you change the working path of e.g. Release 1.0, it will also change the working path of your check-out of Release 1.1 and head.
 
Regards,
Nicola

[Helmut Ortmann]

Hi Nicola,

If I understand you right you want to have a repository like
- Projetct which uses Release 1.0
- Projetct which uses Release 1.1
- Library Release 1.0
- Library Release 1.1

If you want such a solution you have to ensure that every release has in effect its own objects with own identitiers. In other words a copy. I think later you want to reconcile your project with another library release.

Handling different releases of the same object in one repository isn't an easy task. You have to make multiple copies and...

I daubt that this is manageable. Too complex.

You have a chance if you use a repository for each project with it's library release.


Regards,

Helmut

Attachment: (some thought, I'm not sure if they help you)
I'm not an SVN guru. An SVN tag is just a revison which is tagged and has a working copy location which represents all the files of this revision, isn't it?

Why don't you define an SVN TAG for let's say REV 1.0 and for REV 0.1. Then you can assign each project (different EA repositories) to another release of your library/tag.

What you can't easy do is to have different releases of your library in one EA repository (eg.:*.eap file). This is because then you have different release of the same thing in one repository with the same ID (in EA GUID). There might be also solutions but they will require a lot of thinking and work.

[Nicola]

Hi Helmut,

Attachment: (some thought, I'm not sure if they help you)
I'm not an SVN guru. An SVN tag is just a revison which is tagged and has a working copy location which represents all the files of this revision, isn't it?

Yes, creating a Tag/Branch, creats a copy of the Trunk into a different folder in the SVN repository.

Why don't you define an SVN TAG for let's say REV 1.0 and for REV 0.1. Then you can assign each project (different EA repositories) to another release of your library/tag.

That's what I've done. But because the Tag is copy of the trunk, every release/tag/branch of the Framework uses the same UNIQUE ID, which is linked to one Path. This would cause a lot of problems/confusion, if you switch between projects.

Regards,
Nicola