clearcase and EA 7.1 830

[Mr. Sanders]

Hello,

we are using clearcase 6 clients and have some problems with EA in the following way.

Unreserved checkouts are a very important need for our team development.

So User A checksout version X of a package and modifies it
in the EA project file.
User A closes EA.

Than User B checksout the same version X of the package and modifies it in the EA projekt file and closes EA.

User A reopens EA project and his changes are lost, because B has overridden his changes.

Is this a feature or a bug?

Regards
Michael

[Dave.B]

Think of it like this: EA uses a transactional database to store the model. Without a version control system layered on this, all users can collaborate on a single model right down to the level at which EA transacts the changes, which I think is at the modelling element and diagram layout level.

Now as soon as you layer on a version control system, which works at the package level, you added an extra level of control (with the VCS) which is at a much courser level than the basic transactional level of the model's database.

So User A checks out package X and EA captures the changes made by that user to that package. Now if User A then checks-in that package EA will export that package to the package's XMI file stored in the version control system and check it in. If, OTH, User A cancels the checkout, then EA will cancel the checkout in the version control system and reimport the package from its XMI file (thus discarding the changes).

By allowing two (or more) users to work on the same package by using ClearCase's unreserved Check-Out mechanism you are confusing EA because it expects only a single user to have the "make changes" token from the VCS.

Ironically, its seems that version control hinders multi-user collaboration of the same package! Which means, that you have to keep your packages small and not left checked out for too long.

BTW, we had so many problems resulting from developers using unreserved check-outs that we added a ClearCase trigger to our VOB that prevents a user from doing it - its a banned ClearCase command!

Dave B.

[Mr. Sanders]

Hello Dave,

thank your for your answer.
But please read carefully user A and B is NOT checking in nor cancelling. The both checkout.

I think you are mixing two things.

The courser level is valid for the xmi/xml file, but as soon the file is checkout, the user is still working with the transactional db engine on the model and this is the problem.

The model in the db is changed.

all changes done are done in the transaction db model.
thus overriding the changes of the other (isn't it?)

And of course we are keeping the packages as small as possible.

We have to much developer to disallow unreserved checkouts (450+).
And we can not trust that all of this developers do clean reserved checkouts and do not  forgett to check in, when they go home or into vacation or any other heart attack reason or whatever.

So unreserved checkout is a must.

we do merges all the time.

This is not our problem.
The problem is how EA handles the checkout out model parts.

The changes of A/B should be visible to others when he checks in.
And not earlier.

Regards
Michael

[Eve]

Michael,

EA does not support unreserved checkouts.  If EA is allowing a second person to check out a package, then I either Clearcase is misreporting the file status, or there is a bug in EA.  (I know we have seen VC providers mis-reporting status before.)

If you are using a shared database for your models, any changes to a package will be visible to anyone else using that database.  If you don't want that, you'll need to use individual eap files.

Have you read the whitepaper on deployment of EA?  That covers some of these issues.

[Mr. Sanders]

Hello Simon,

thank you for your answer.

So, what you want to say is: It is a feature.

Right?

Regards

[Dave.B]

Michael,
At the risk of getting into mud slinging, I'd like to suggest that the systematic use of unreserved checkouts in ClearCase to support concurrent development is a bad and uncontrolled practise. In Base ClearCase you should use branches for this purpose.

we can not trust that all of this developers do clean reserved checkouts and do not  forget to check in, when they go home or into vacation or any other heart attack reason or whatever.

I don't think that this is a problem with ClearCase or EA... and in any respect your VOB admin can easily rectify such problems.

ClearCase is fairly unusual in providing the capability for unreserved checkouts, so you should ask yourself how other people and teams cope with your problems when using other VCS systems.

But please read carefully...

I did! But may be my answer wasn't as clear as it should have been.

The problem for you is that EA assumes that a VC lock is obtained by one user, and whilst it will seemingly transact changes from more than one user in the scenario that you describe it is really only intended by design to work for one. I think that there are some holes in the implementation, because with ClearCase's unreserved checkouts it is possible to create a mess such that the model becomes unsynchronised with the checked in XMI package files.

So the fact that you can do some thing that you shouldn't be able to do is a bug in EA, but one that can be avoided by the simple expediant of not allowing unreserved checkouts.

This of course raises the question of collaborative working and being able to work on VCS branches of packages and model merging, for which I would like to have some good answers. (So far we have only tried the one deployment with ClearCase.)

Regards
Dave B.

[Mr. Sanders]

Hello Dave,

no  we are additionally using branches.
We are working for different countries (so have different laws and different implementations),
different version and different hardware.
Sometimes we have different plattforms too.

For all these cases we have to use branches.
if you take all developers there are about 3000+ working on the whole world spreaded in different countries using synchronised vobs

We are using unreserved checkouts since over 10 years and don't have problems with them.
We allways have problems with reserved checkouts.

It is not the job of the vob admins to solve such reserved checkout problems.

Of course they can, but you have to avoid it in advance.
Therefore use unreserved checkouts.

But this is a philosphical discussion.

Our problem is the EA.

In fact when the EA handles it in this way, we have to enforce it on the EA files via trigger (maybe).

Maybe we are using private models.

Regards

[Eve]

If you are wanting to use unreserved checkouts, then yes it would be a feature request.  There is the capability in EA right now to merge from a baseline (or XMI file) into the model.  So you could potentially use that to achieve the same thing.  It seems to me that what you need is for EA to detect the problem and automatically open the comparison window.