Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Mr. Sanders

Pages: 1 ... 11 12 [13]
Automation Interface, Add-Ins and Tools / Re: Check-in files in Clearcase
« on: October 16, 2007, 09:46:03 pm »
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?

Automation Interface, Add-Ins and Tools / Re: Check-in files in Clearcase
« on: October 16, 2007, 08:42:36 pm »
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.

Automation Interface, Add-Ins and Tools / Re: Check-in files in Clearcase
« on: October 16, 2007, 02:38:07 am »

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.

Automation Interface, Add-Ins and Tools / Re: Check-in files in Clearcase
« on: October 16, 2007, 01:16:37 am »

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.

Automation Interface, Add-Ins and Tools / Re: EA 7.0 and clearcase
« on: October 12, 2007, 01:49:32 am »
Hello Guenter,

thank your for your answer.

Of course this is a problem, because checkin AND labeling is done via clearcase scripts.

And now the user is forced to use the EA checkin mechanism.

If the xml file would be generated during modelling, the user coud choose.

Either use the EA mechanism, or use the EXISTING process and scripts from clearcase mechanism.

The way it is, it enforces to adapt the process to the tool and this never was good choice.

Is there a way to enforce the EA, the the xml files are directly modified without checkin from EA?


Automation Interface, Add-Ins and Tools / EA 7.0 and clearcase
« on: October 08, 2007, 09:22:18 pm »

we observed some (in our point fo view) strange behaviour.


One EAP file
two parallel packages
both of them are under clearcase (cc) control.
both of them are checked out.

Now we move a class from package A to package B.
Now close EA.

If we compare the xml files of the packages A and B with its predecessor in CC, NO differences are found.

Thus we have problems checking them in, because CC is telling us, that they are identical.

When we reopen EA all changings are still there.
When we now check in packages via EA and compare the xml files, the changes are visible as differences.

It seems, that the changings are written to the eap file, and only a checkin via EA is possible.

Is that correct?

If yes, this is not usefull for team development.
We have to work with the clearcase tool to handle all the other artefacts belonging to the project too. And this has to be done with clearcase.

How can we enforce EA to write the changes into the XML file, so that we can checkin with CC?


Pages: 1 ... 11 12 [13]