Version Controlled items and relations

[Krzysztof Swiatkowski]

Hi,

why it is not possible to add a relation from a checked in item to a checked out item?
I have actors that are located in package that is checked-in and if I want to connect them to a use case I must check-out the Actors package.
This way Actors package is beeing checked in and out by anyone trying to use an actor for something. And terrible things happen to people who forget to check-in that package immediately after use
Is it a bug or feature?

Regards
Kris

[Frank Horn]

why it is not possible to add a relation from a checked in item to a checked out item?

It is, but not vice versa. A connector is added to the package containing the source element, so the source but not the target needs to be in a checked out package.

I have actors that are located in package that is checked-in and if I want to connect them to a use case I must check-out the Actors package.

This is because one usually associates them by defining a "use" connector with the actor as source (indicating that the actor uses the case). I just don't do it this way when we have a controlled package with actors. A possible way out of this is to put an instance of the actor into the use case package and let the instance use the case (not offered by quick link, but possible). Or a dependency from the use case to the actor.

I'm not sure what the UML gurus think of this, but I don't really care. Usually I only try to model the minimum information I need, and with minimum effort.

[Krzysztof Swiatkowski]

I know that you can do it that way but I think that it should be implemented in a way that you could add relations. Locking by the checkin should only be applicable to changing element properties and existing relations. Though this could make package exports and imports a complicated thing to do.

Just my 0.02$
Kris

[mrf]

In most cases adding a connector between two elements modifies the semantics of at least one of the elements in some way.

The general rule is that you cannot add a connector between two elements if the element that will be changed by adding the connector is locked.

In the case of generalizations the source would be the item modified (as the source element generalizes the target element, therefore the source element definition changes). Therefore if the source element is locked you would not be able to create a generalization.

In the case of aggregations, the target element is redefined by adding a connector, therefore aggregations can't be added if the target element is locked.

[marcelloh]

I thought that one of the advantages of having version control, is that some of the action could be "auto-magically" merged by the version control system. So 2 persons can continue to work without having a network connection and when they update, the merging will take place. (And conflicts will be mentioned of course)

[Krzysztof Swiatkowski]

Unfortunately support for Version Control Systems is in EA very simple.
EA support ends at the point when it generates XMI file and let the VCS worry about it. Merging is not supported and locks are enforced. You can merge if VCS supports it outside of EA and in case of XML file it isn't much which is kind of a PITA if you want to use branches.
I think that real package merging support would require some serious support on the EA side, but then it might be hard if possible to support various VC systems.

For me it was a surprise that EA does not support atomic group checkins, it is always checking in one package at a time (when checking in multiple packages via Check In Branch). Which is a bad way of doing it in Subversion or any VCS that supports atomic checkins, where all modifications are checked in at once and it is harder to end up with inconsistent repository.

Regards
Kris