> On NT, you don't really have a view set in the GUI.
> You change views by changing drives or by changing directories
> on the M: drive.
One can map a view to a drive on NT, in fact I believe it to be the standard
practice.
Hi Mervin,
We generally have one single view per developer. This saves a lot of hassle
from the admin
point of view and even sometimes for developers, as some people "forget"
which view they
were working with and thus become confused and call you for help!
To avoid confusion with config specs, we have a build system which keeps
track of config-specs
and we are very pro-baselining. If you get developers into proper
baselining, then even
re-creating a config is not a real hassle.
A build system can be a bit of a hassle, so why not create little shell
script, a wrapper for
ct setcs/edcs. So tell the users to run setcs or edcs instead of ct setcs
etc. and every
time this is run, it can catcs the config-spec into a versioned element. So
if the user
wants to see their config spec as it was at 12:00, then simply do a ct find
on the element for
the version number based on time or change your config spec to it etc.
Hope this helps.
----------------------------------------------------------------------------
--------
Alex Batlin | alex.batlin@nomura.co.uk
Nomura International plc, Nomura House | Phone: +44 (0)20 7521 3728
1 St. Martin's-le-Grand, London EC1A 4NP | Fax: +44 (0)20 7521 3686
----------------------------------------------------------------------------
--------
The information contained in this message is intended for the named
recipients
only. If you are not an intended recipient of this message, you must not
copy,
distribute or take any action in reliance on it and you should notify the
sender
immediately. E-mail transmission cannot be guaranteed to be secure or
error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or
incomplete, or contain viruses, and Nomura International plc excludes
liability for
(1) any errors or omissions in the contents of this message which arise as
a result
of e-mail transmission and (2) the transmission of any viruses. If
verification is
required please request a hard-copy version. Nomura International plc is
regulated
by the Securities and Futures Authority Limited and is a member of the
London
Stock Exchange.
----------------------------------------------------------------------------
--------
-----Original Message-----
From: Marilyn Sander [mailto:marilyn@hal.com
Sent: 24 January 2000 21:03
To: Mervin_Manangan@Instinet.com; cciug@Rational.Com
Subject: Re: [cciug] Suggestions/Comments needed (any)
I would *not* keep changing the config spec for a view. I
tried that a couple of times, and eventually got in trouble
because I would forget what a view's config spec was set to.
If your users need to see what changed between one
element version and another, they can easily use cleardiff
from either the GUI or the command line. You will want
to teach them how to understand and use the version extensions
on element versions. Use the versiontree tool in the GUI,
or lsvtree from the command line, to see what versions
an element has.
To record what config spec is used for a build, I include
a catcs in the build script and a cleartool pwv.
As a UNIX user who pefers the command line, I just have as
many views as I need for working with the various config specs
that I want to use. I keep a command line window open to
each view I want to use. I do the same thing on NT, using
MSDOS command line windows.
As for GUI use, I think you can
have several GUI windows open on UNIX, each with a different
view. On NT, you don't really have a view set in the GUI.
You change views by changing drives or by changing directories
on the M: drive.
In my experience, most developers just have 1-3 views they use.
It doesn't become a big administrative hassle.
--Marilyn Sander
| From: Mervin_Manangan@Instinet.com
| To: cciug@Rational.Com
| Date: Mon, 24 Jan 2000 15:32:06 -0500
| 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
|
|
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|
|
|
| http://clearcase.rational.com/cciug/mailing_list.html
-----------------------------------------------------------------------
Marilyn E. Sander, CM Engineer marilyn@hal.com
Fujitsu System Technologies (408)341-5590
Division of HAL Computer Systems, 1315 Dell Avenue, Campbell, CA 95008
-----------------------------------------------------------------------
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:22:35 EDT