Don,
This was such a concern that it was a priority functionality bit in
ClearTrigger 2.0. NO code to write just flip a bit. It was tested on VOBs
that previously took 5-15 seconds using the perl script on our site.. and
4-8 seconds on the script that Paul Smith wrote (I used that one also at
times) The version on the tool performed the same test all in under 1
second. It is much faster and you don't have to code it and it comes
will all the other stuff as well.. You would only need 1 or two licenses
no matter how many ClearCase users or VOBs you have and you could create
lots of other policy by flipping bits or adding keys and have it
immediately apply to ALL VOBs instantly. The result of ClearTrigger 2.0 is
policy management at the company or region level instead of the VOB level.
It has a GUI interface for policy definition. You can download a fully
functional copy from our site
Hope this helps
-Charles
Try ClearTrigger and ClearTrigger Lite at http://www.abs-consulting.com
A Better Solution, Inc.
----------------------------------------------------
Charles Clarke III ClearCase Consultant
A Better Solution, Inc. (770) 252-1500 x22 [phone]
1973 East Hwy. 34
Newnan, Ga. 30265 (770) 252-1501 [fax]
Email:
charles@abs-consulting.com
http://www.abs-consulting.com
At 09:48 AM 7/13/2001 -0700, you wrote:
> There was a discussion a while ago about the infamous "evil twin"
>problem.
>Unfortunately I can't find the references to this so I apologize if I'm
>repeating
>the discussion.
>
> The "evil twin" phenomenom is where mulitiple elements exist for the
>same name and path which will
>happen if rather than performing a directory merge between branches to
>make
>an element visible, the user performs another mkelem for the element.
>What you end up with is an element (or should I say elements) with
>multiple
>histories ie. version trees.
>
>I would like to know if anyone has any tools to detect all occurences of
>this,
>and any tools to merge the twins together retaining the history.
>
>I have a trigger enforced on mkelem at this point which disallows this
>but it
>is rather inefficient since it checks all directory versions of the
>parent of the new
>element for each new mkelem. I was wondering if anyone has found a
>better
>solution to this also.
>
>Thanks for any help,
>dskanes@vpacket.com
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 22:03:54 EDT