Hi Mervin,
Here are a few thoughts hat come to mind.
Why should you not keep the same view and just change your config spec?
1) Your new config spec may not select a directory previously available in
the old config spec, which had :-
a) view private files, which include DO's and new files (not added to
the vob)
b) checkouts
This will cause those files to become invisible ie. no longer
accessible,
unlesss you change back your config spec.
2) DO's can become hidden from (1) above, therefore having an overhead
in the view storage, whereby the view is carrying extra baggage around.
This may impact performance, DO shopping, backup and DO access.
All DO's CR's are initially stored in the view db space, so if the view
DO's don't get deleted, then this space will increase.
3) The view name and the config spec can be no longer synchronised, whereby
the name no longer matches what the config spec is selecting in
functionality.
When should you keep your view and just change your config spec?
1) You view is a readonly view, where you don't perform checkouts.
Perhaps used during impact assessment or fault investigation.
2) Your view selects a sound baseline, and a new baseline is available
and you want to move to that new baseline.
The time taken to delete and re-create a view is generally minimal, compared
to the time it would take to resolve any issues caused by the
misconfiguration
or over re-use of a view. Very difficult to track exactly what went wrong
when.
My recommendation is for users to use a view for a particular task, once
completed, the view is to be deleted.
Finally, if your users practice the re-use of views and this becomes
problematic.
Then you may need to consider placing a front end to cleartool, and capture
the changed config specs, to allow you to effectively picture what changes
took
place when.
I wish Rational would allow us to have a trigger to capture the changing of
config specs !!!.
Cheers,
Sebastien.
----- Original Message -----
From: <Mervin_Manangan@Instinet.com>
To: <cciug@Rational.Com>
Sent: Tuesday, January 25, 2000 7:32 AM
Subject: [cciug] Suggestions/Comments needed (any)
>
>
> Hi all,
>
> I have a puzzling question thrown at me by one of our Development heads
here and
> here it is:
>
> Q. Is it advisable to have developers freely re-use their views (switch
what
> they see and make comparisons) by just changing back and forth their
config
> specs?
>
> A. I groped for a clear - nonconfusing - answer but was dumbfounded.
>
> First I thought that in order to save me the "what happened here?"
question by
> users, I would recommend them creating new views with the config spec they
would
> want to compare with with their current view. Just leave your current
view's cs
> as it is and then change the new view's cs. But then again, the overhead
of
> maintaining this practice might fall into my hands of religiously cleaning
up
> DOs and views. Also, if they run makes (depending if they use -u or -V or
even
> -F depending if the machine where the build is run is consistent and
stable -
> not much changes), would it still be affected by undesired wink-ins?.
>
> Then secondly, I thought, if they do just keep a single view and change
back and
> forth their cs, we would run into the confusion of having the DOs still
there of
> the previous make and running a new make still have them around. Going
back to
> the old cs would just make it all confusing. Sure, catcr may give us the
> history of what view and when it was produced but the status of its
configspec
> then is nowhere found. Users have this notion that if they change
configspecs
> it's a new/fresh view - BUT it isn't! Things done/created by certain
views
> doesn't guarantee of a good record of its state if config specs are freely
> changed often but I guess Rational never really have a safety
feature/control on
> editing configspecs.
>
> Thirdly, since number 2 thought is still a puzzle to me, I figured to
place a
> wrapper on makes or view-creation that would capture it's config spec and
place
> it somewhere and refer to it when a make of a certain file is done so
that I
> would have some kind of a record of it's state aside from where and when
it was
> built. This is a giant task though... Still I'm in the dark.
>
> Surely, some of you may have done something to answer the Q above and may
have
> better insights as to how I can better manage views, config specs, DOs and
> record-keeping. If you could, please share them. I would highly
appreciate
> it.
>
> Thanks in advance,
> Mervin
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:22:35 EDT