Check-in files in Clearcase

[antropeter]

Hello All,

I am new to EA and trying to find out how can I use team-collaborative design using EA.

I had successfully connected to Clearcase (SCC) from EA, now my question is what files in EA I need to check-in to clearcase, so that other team members can start their check-outs and add changes and check back in.

Do I have to check-in just the "EAP" project and all users have to check-out just that file, make changes and merge/check-in accordingly?

Any help and additional information on this is GREATLY appreciated.

Thanks!

[lubos]

Hello,

I'm quite new to EA too but I will try to give you some overview how we use ClearCase with EA in our company:

It's not useful to versionate EAP file since it's database (binary file) and if you use some  database server to store the model it's not even possible.
It's better to select some (sub)tree (package/model) of the model and configure "Package Control" to store the content of the package to XML file. You will have the options to checkin or checkout this package available after this setting and versioning of the XML file makes more sense.

Not all parts of the model can be versioned in this way - for example defined stereotypes or another "Settings" issues. These can be serialized by "Tools - Export Reference Data" which creates the XML export file too, that can be versioned as well.

If anybody has same other experiences with EA and ClearCase I interested as well...

[antropeter]

Thanks for the response! So as per the response, it is not wise to check-in EAP files and we can configure individual models as xml files and check-in the xml files.

How does the other team member open that xml file within the same EAP project in their machine?

Thanks!!

[OilyRag]

Hi,

lubos is correct here - dont versionate your EAP files, but rather your model views and for finer granularity, the sub-packages within model views.

In the company I work for, we have experienced some problems with team collaboration.

In general, it is not wise to have >1 person checkout and work on a version controlled view or package. So, you have to bite the bullet and go for finer granularity, or adopt a modelling buddy approach to working on a model, where two people sit at one machine and so only a single checkout is performed. We haven't tried the latter because we don't historically have a culture of doing things like that (a damm shame if you ask me) so there is management resistance.

I would also recommend that all modellers working in your project setup their clearcase clients to perform reserved checkouts, and to demand that if any one of them attempt to checkout on top of another checkout made by another user, they abort it. By using reserved checkouts, a second modeller attempting to do the checkout will get a warning. They should not ignore that. If you do not adopt this, then you will sooner or later have to face the XMI merge scenario - a nightmare. Dont go there, if you can avoid it.

Once you adopt fine granularity of version control, then you might need to impose on the team the use of a shared repository, otherwise each user with their own EAP file may organize the version controlled items in different ways (ie, under model view and parent package hierarchies that differ from other users), which may or may not be important, but nevertheless may lead to one modeller having trouble working on anothers machine/PC.

Think carefully before choosing to share an EAP file. Read Sparx System's own advice on thise matter. They have a white paper about all of this on their website. It is far better to setup a MySQL or Oracle based repository, for example.

[lubos]

..I just add some hints to OilyRag explanation.
I agree that it's better to have fine-grained model divided into small XML files that only one person can work with.
If you need to enable to work more people on the same part of the model at the same time, we discovered the most secured way is to use the same view under ClearCase by all these poeple-- but we try to avoid such situations anyway.

[OilyRag]

Lubos, re. a shared clearcase view, that is an excellent idea. Thanks for the tip.

[Mr. Sanders]

Hello,

I have some other additions:

You have to use the EA checkin mechanism and NOT the clearcase checkin command.

The reason is, that the new subpackage XML file is generated, when the checkin is triggered from EA.

If you would close the EA after checkout and modifying the sub packages and then try to checkin via clearcase, clearcase tells you, that the file to checkin is identical to the last version.

The differences seem to be kept in the eap file.


This has some cumbersome consequences to us.

Normally we checkout files and modify them as needed.

Than we use clearcase scripts to label the checked out files and then check them in.

Thus all modified files have the same label.
Because you normally modify other artefacts like source file
too, this is the natural thing to to.

This is not possible with EA.

You have to check them in via EA and then you have to keep the history of modified XML file in mind, and then use clearcase to label them.

Additionally you also have to use clearcase to label the source files, which are still checked out of course.

It would be very nice if the XML file would be written as soon as modifications are done in EA. Thus the user has the choice how to work.

The current implementation enforces the user to use EA as the checkin frontend.

[lubos]

That's correct and it's a result of how EA works with these XML files.
EA works primary with its DB (EAP file|DB server) and XML file is used only in time of (de)serialization of a part of the model from/to it
and  as a lock of the part of the model.

You can try that if you have diconnected the CC view you use to store XML files so that  EA couldn't find them, you can modify the model even if it's not checked out. -- it's also very dangerous thing ...you can loose some work if you do this, and another one will do regular checkout replacing the part of the model from the XML file.

[Mr. Sanders]

Hi,

no, the cc views are not disconnected. They work very well, we never had problems with them.

Woking on the model without checking out is nonsens to us.

Either check it out unreserved and than do a undo checkout or don't modify the model.

What we would like to have, is that the xml files are immediately written to disk, when you model the package and NOT only when they are checked in via EA.

The behavior of the EA is not nice here.

[lubos]

It was maybe misunderstanding of my reply.
I didn't say you have the problem with disconnected view, I just described behavior we discovered when the view is disconnected.

EA uses/touches  XML file only in these situations as I know:
1) checkin to CC --> serialize the part of the  model into XML
2) checkout from CC --> deserialize content of XML file into model (the current content of the model is deleted)
3) checking if the part of model is permited to modify (is checked out) --> works onky if the EA sees the XML file

Changes  are not continuously written into XML, as you already discovered.

[OilyRag]

I dont see how it is reasonable to expect the XMI serialisation back to the checked-out clearcase element to happen on every minute change made to the model in EA. Even relatively small models can take some non-trivial time to serialise (several seconds). Imagine what it would be like, having to suffer that every time you did something to the model, even a trivial change like moving a diagram element by 1 pixel, etc. Some of our large models take over 20 seconds to serialise. Its just not practical.

On mizd's point about the way they use clearcase, specifically how they want to label changed elements atomically via scripts, one way would be to use a work in progress branch to do the work, checking in and out via EA. Then use a script to atomically merge back to the integration branch all of the XMIs that were branched, label the checkouts that result from the merge, and then checkin.

[Mr. Sanders]

Hello OilyRag,

we were working about 7 years with rational rose. And what you are talking about not beeing practical was very neat with rose.

Your answer goes into direction: Adapt your process to the tool's behaviour. And this is not fine.

What's practical and what not must be defined by the user. We are already working on 10 to 15 branches resulting from different hardware, different countries (law), different development site. The code is shared by 1000+ developers in about 6 countries. You have to have strict rules how to work and adapting the process means changing the work for 1000+ people.

What do you think is better?
A tool where the process must be adapted to its behaviour, or a tool which seamlessly integrates in existing (huge) processes.

By the way, there wouldn't be the need by an immediate update of the xml file. A time triggered cyclic save and a user triggered save and an ea close triggered save would solve our problems.

[OilyRag]

mizd...sounds to me like EA is not the tool for you. Are you doing an evaluation of EA before rolling it out to your workforce? I hope so.  

BTW, we used to use Rose here too but found its licensing/support costs too high. I suppose we are adapting to EA and for us that turns out to be fine,...so far that is.

Maybe someone else can answer this question...Can you initiate a serialisation to XMI via the automation interface. If you can then you could write an add-in to let users do that as and when they want.  

[Mr. Sanders]

Hello OilyRag,

we took rose and threw it in another universe, because of the pain in the a.. we had with it (aside the galactic costs). My person self found over 50 bugs in it. Now it rests where it should be.

We are currently evaluating EA and we think it is the tool we need. The 1000+ people are not sharing the same model, but the same sw-process.

The automation interface sounds interesting, but documentation aboud it is a bit thin.

Is there anybody who can give me a hint were I can read about creating the xml file via automation?

[lubos]

This is a good starting point:
http://enterprise-architect.biz/EAUserGuide/package_2.htm

but this part of API (controlling versioning) we have not tested yet, so I can't give you any other advice except one:
Be patient, documentation is very poor, and API is still developing  so that it's quite buggy and official support not answering.