Demos on what is coming in ClearCase   

Hello,
I am writing about the recent article containing demos of future ClearCase (and ClearQuest) features. The article itself is now at this URL: http://www.ibm.com/developerworks/rational/downloads/07/cccq_future_enhancement/

Rational Product Managers are hoping you'll take a look at these demos. They welcome your feedback, questions and ideas to best inform their decision-making as they guide the product forward.

Several of the demos in the article are provided in .avi files. These will require a special Camtasia codec to properly display the video portion. You can download this codec at http://www.techsmith.com/codecs/tscc/default.asp

Sincerely yours, Marc

.......................................................
Marc Siegel
IBM Rational developerWorks Community Manager
408.463.5278, email: marcsiegel at us.ibm.com, AIM: marcsiegel10

Uwe,

Good point about beta testing those new features!

To my knowledge IBM has a beta-test program for new releases, where any customer can participate. Is this the kind of testing you are referring to, or do you mean you want to participate in earlier testing (i.e. on the prototype)?

Note that the Discussion Facilitators will gather the responses on the demos and discuss this with the Product Managers.

Regards,
Frank.

• ClearCase Discussion Facilitator -

TOPIC Embedded Systems
Best, the Netherlands

this is what a trigger is supposed to do.
and rename the private file to ".something".
jp
_______________________________________________
cciug mailing list
cciug@lists.ca.ibm.com
Unsubscribe:cciug-leave@lists.ca.ibm.com

I've just listened to the CCRC demo, great stuff and it will certainly drive the integration of LAN support in CCRC to get the new operations for everybody.

One specific comment: We use Base ClearCase and include rules in our config specs. It would be nice to add re-evaluation of the config spec as one more option in the Pending Changes features list, as a suboption to the incoming changes I guess.

Hi Frank,

I know, that for each new release a beta-tester program for customers exist.
but I would like to participate in the prototype testing, means much earlier as if participating to the release beta-testing.
but I'm only a freelancer, no IBM customer. don't know whether IBM is willing to
let freelancers participate to prototype testing.

one remark to the evil twins implementation:
in general it is a good approach.
but if I were responsible, I would implement a more general concept, let's call
it a "name scope concept".
I would allow to group directories together into one name space, and then to avoid evil twins in this name space. The default would be to have each single directory in its own name space, but still the possibility would exist to extend the "single source/name principle" to a wider scope (=set of directories).

one remark to the atomic checkin:
very good, but also for this I would like to see a more general approach - a transaction model.
start transaction -> perform several ct operations -> rollback (or do not commit) if any of the operations fails, commit transaction if all operations finished successfully, where (more precisely):
commit of a checkout => checkin
rollback of a checkout => uncheckout
commit of a checkin => nothing
rollback of a checkin = remove version (eventually remove branch)
rollback of a findmerge => uncheckout all performed checkouts
and so on ....
at least it means to split cleartool commands into start-ctcmd, commit-ctcmd, rollback-ctcmd.
and the atomic checkin would just be one special usage of this concept, which could be seen as one default usage of the general implementation. Ok, granted, the atomic checkin has one other benefit which is not addressed by the above
mentioned transaction model : speed in checkin, because not performing one checkin after the other.

I have implemented such a thingy in a Perl interface to cleartool, and for scripting it is very helpful.

Cheers
Uwe

--
Dipl. Inform. Uwe Satthoff ( us@comasy.de )
currently consultant @ Airbus ( Uwe.Satthoff@airbus.com )

I agree partially.
what about this:
there are three modes:
1. abort operation with error message
2. create hard link and do further processing, if only ONE other DB object exists.
3. pre lnname trigger processing

for 2.:
if a pre lnname all element trigger type of a predefined name, e.g. evil_twin_trg,
exists, then this alternative 2. is executed, means the trigger will be executed.
in an env var a list of all distinct evil twins is provided. distinct means if this are really different DB objects (there are already evil twins).

and then in addition I would like to have one additional return code for pre-op triggers, not only 0 or 1. The additional return code means, just do nothing, because the trigger has done all work.

Cheers
Uwe
--
Dipl. Inform. Uwe Satthoff ( Uwe.Satthoff@conform-it.de, https://www.xing.com/profile/Uwe_Satthoff )
currently consultant @ Airbus ( Uwe.Satthoff@airbus.com )

> I would like a way to choose myself the way I want to
> recover the evil twin. I would like to be able to
> process the case of slink evil twin in a way, the
> case of a name of a directory changed to the name of
> the file in an other way, the case of a renaming in
> an other way. I would like to be able to decide if I
> want to test the element oid before recovery.
>
> It would be good to have two modes: in the first
> mode, the error message is displayed, nothing more.
> In the second mode, a trigger environment variable is
> set in the post-operation trigger (mkelem, mv, ln,
> ...), giving the version of the parent directory
> containing the existing element (or slink). No error
> message in this case, and the trigger can do the evil
> twin processing.
>
> Unless IBM-Rational defines clearly the way to
> recover, it is better to let the people use their own
> algorithm.
>
> 0.02
> Olivier

--
Dipl. Inform. Uwe Satthoff ( Uwe.Satthoff@conform-it.de, https://www.xing.com/profile/Uwe_Satthoff )
currently consultant @ Airbus ( Uwe.Satthoff@airbus.com )

Hi Marc!

I have got some questions, I understood I could ask them here (?):

1) Is the change of vob database format only for evil twin tracking, or is there "more" inside??

2) I like the idea of the evil twin demo, BUT I need to know: how do you do the search for evil twins?
Do you cover: obsolete branches (or not), checked-out directory versions (or not), checked-out directory versions of remote replicas (or not)? My trigger does all this, is it the case of the demo algorithm?

3) I search for the most recent evil twin, and I stop the search. Because the goal of the trigger is to avoid ev tw, I take as assumption that there is no more than one possible conflict. This is a choice. How it is with the demo algorithm?

After that, it is clear for me that I need to use this real improvement that many wait since years. I understood that it is a one pass process. So I expect the result of the search in the post-op trigger, and I do not want to add my trigger before operation anymore.

> there are three modes:
> 1. abort operation with error message
> 2. create hard link and do further processing, if
> only ONE other DB object exists.
> 3. pre lnname trigger processing

Ok for three modes, Not bad, BUT: I expect to do the recovery in the post-op trigger. Ok to put it on lnname. After that, IBM-Rational could propose a default processing, the hardlink is created, this is the basic idea. That could be something implemented directly, not a default trigger.

But users need also to be able to do something else, maybe more complex.

The element to add can have the name of file/directory/slink. The existing "evil twin" name can be of file/directory/slink.
If it is not the same kind, I decide that there is NO real evil twin - this is a choice.

If it is a file for a file, the hlink is created automatically. If it is a slink for a slink, this is two different objects - no evil twin here - no recovery necessary.

But if it a directory - Ah! - this is a real problem, and the recovery is not automated - NO recovery in this case. Call CC Admin. Because a directory contains files, and maybe other directories. This is often not a hardlink that is required, but maybe more a findmerge from an old branch to a current one.

> So for us, the proposed env. variable that a user
> has/can set is not ok.

I like this remark: the configuration of the evil twin search algorithm is maybe to be added to the installation configuration?
Users should not be able to modify it dynamically.

> having the underlying new quick search funct
> available as an API in a trigger would seem more
> appropriate to implement the correct policy with
> correct performance.

If we ask for an API, we will use a pre-op trigger, which is less efficient than the use of the database key. I am afraid we will loose much of the new implementation, no?!

Olivier