Frances,
A bit of tweaking solves it....
I would not suggest using on mkelem....
try checkin... instead... after all whey you do mkelem the /main/0 is
always empty.... and probably not worth the copy to your location. The
first thing you would probably want to copy is /main/1... use the post
checkin trigger method..
apply #2 and #3... as far as it firing on each element below ... I hope
that would not be too costly (just do the check for eltype early in the
script).
-Charles
At 04:14 PM 1/21/00 -0500, ffarmer2@csc.com wrote:
>This was the first thing I came up with, your #2 (depending on the inheritance
>to do it), but I was told it didn't work since the new element didn't
>exist when
>the preop trigger would have to fire. And your #3 was my next try, but they
>wanted to avoid having to execute a trigger on non-affected elements. I guess
>the problem is really that I am only working as an advisor here, and haven't
>tested these myself. I appreciate your input.
>
>Do you agree that we are working this the most practical way? Is there some
>reference that you know of that would help? We tried to throw money at
>Rational
>to get them to port Clearcase over to Concurrent but they wouldn't
>budge. This
>is a long-term project and is just starting out so we need to do this
>right the
>first time and fairly bulletproof.
>
>Thanks,
>
>Frances
>
>
>
>
>cciug@abs-consulting.com on 01/21/2000 02:09:32 PM
>
>To: Frances L Farmer/DEF/CSC@CSC, cciug@rational.com
>cc:
>Subject: Re: [cciug] preop mkelem trigger and duplicating vob
>
>
>
>ffarmer2,
>
>If when you say the C++ files under /vobs/vobname/c++_src "recursively"
>you could do this:
>
>1) instead of "-ele -all" trigger restricted to by -eltype create
>a "-ele" trigger.
>2) attach this the directory /vobs/vobname/c++_src like so:
>
> ct mktrigger trigger_name /vobs/vobname/c++_src
>
>by default this will attach to all files and subdirs that exist there (via
>attachment list - refer to ct man mktrigger)
>by default this will also attach to all newly added files and subdirs (via
>inheritance list - refer to ct man mktrigger)
>
>3) place something in you trigger code like so (pseudo code):
>
> if (CLEARCASE_ELTYPE == c_plus_plus_source) && (CLEARCASE_ID_STRING ==
>/main/LATEST)
> "do your copy"
> else
> exit 0
>
>Hope this helps
> -Charles
>
>--- VOB Corleone
> "One day.. and this day may never come... I might ask you for a
> favor.."
>
> A Better Solution, Inc.
>----------------------------------------------------
>Charles Clarke III ClearCase Consultant
>A Better Solution, Inc. (770) 252-1500 x22 [phone]
>50 Springridge Ct.
>Newnan, Ga. 30265 (770) 252-1501 [fax]
> Email:
>charles@abs-consulting.com
>
>http://www.abs-consulting.com
>
>
>
>At 01:20 PM 1/21/00 -0500, ffarmer2@csc.com wrote:
>
>
>
> >We are trying to maintain a copy of our latest vob structure outside of
> >the vob.
> >The reason for this is our compiler and Clearcase are not supported on the
> >same
> >platform (C++ on concurrent and Clearcase on Solaris). When someone
> checks a
> >file in the current copy is copied into the structure in /home/vobadm. The
> >problem we are running into is with the mkelem command. I have
> suggested that
> >we (as vobadm) handle it manually, but I have been asked to automate
> >it. I have
> >a trigger which checks for the directory or file and creates it. We would
> >like
> >to restrict this trigger to only fire for mkelem within
> /vob/vobname/c++_src.
> >We have tried specifying -eltype, but we have C++ source files elsewhere for
> >which the trigger should not fire. Any ideas?
> >
> >/vob/vobname/c++_src
> > /bin
> > /bin/component1
> > /bin/component2
> > .
> > .
> > /lib
> > .
> >
> >
> >and this structure is replicated in /home/vobadm/LATEST/c++_src.
> >
> >We need to avoid the instance where someone checks something in and it
> doesn't
> >show up in LATEST for someone else to compile against. We also have a
> >/home/vobadm/WEEKLY structure with the most recent "blessed" load, but since
> >they can't use Clearcase to access the current files we have to maintain
> that
> >too.
> >
> >Has anyone worked in this situation before? We considered exporting the
> VOBs
> >but decided against it because we needed this dynamic access.
> >
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >
> >
> > http://clearcase.rational.com/cciug/mailing_list.html
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:22:34 EDT