Testing config. specs in clearcase

[Martin]

I was wondering if there is a way to quickly test a new config. spec
in clearcase to ensure ALL elements in a VOB are picked up by the
rules in the spec. Basically, I like to ensure that the rules I
specify do account for all elements in a VOB and no elements are left
out when I go from an old config spec to a new one I create.

Does a recursive "ls" on VOB followed by doing a count on the result
of "ls" an option or is there a better way?

Thanks.

Martin

[Jerome de Vivie]

Martin wrote: I was wondering if there is a way to quickly test a new config. spec in clearcase to ensure ALL elements in a VOB are picked up by the rules in the spec. Basically, I like to ensure that the rules I specify do account for all elements in a VOB and no elements are left out when I go from an old config spec to a new one I create. Does a recursive "ls" on VOB followed by doing a count on the result of "ls" an option or is there a better way?

With a Clearcase "config spec", you can select a version for each
individual element and produce a random configuration which has never
been an historical stats of the filesytem.

As ClearCase permits those kinds of tricky things, you really need the
tool you describe. Unfortunatly, this is not realisable because an
element is not always referenced in his parent directory.

"Version oriented" tools like Clearcase are not designed for managing
correctly configurations.

regards,

--
Jérôme de Vivie

[Frank Schophuizen]

> "Version oriented" tools like Clearcase are not designed for managing correctly configurations.

What do you mean by this?
It sounds like a harsh accusation against "version oriented" tools.

Frank.

[Frank Schophuizen]

"Martin" wrote: I was wondering if there is a way to quickly test a new config. spec in clearcase to ensure ALL elements in a VOB are picked up by the rules in the spec.

Before an element becomes visible in a view, two rules must be satisified:
1. the directory path to the element must be visible
2. an element version of the element must be visible

For example:

Version /main/1 of directory "mydir" contains foo.c and bar.c
Version /main/2 of directory "mydir" contains bar.c
Version /main/3 of directory "mydir" contains bar.c and menu.c
Given this config-spec:

element * /main/LATEST

This shows the LATEST configuration on the main branch. If you perform a
recursuve "ls" you will find only 3 elements (mydir, bar.c and memnu.c),
while the VOB contains 4 elements (mydir, foo.c, bar.c and menu.c). Yet, it
is correct.

Since foo.c and menu.c never occured in the same configuration
simultaneously. In other words, you should not test your config-spec to show
ALL elements in the VOB, but to show the CORRECT element versions in the
VOB.

Frank.

[Jerome de Vivie]

Frank Schophuizen wrote: "Version oriented" tools like Clearcase are not designed for managing correctly configurations. What do you mean by this? It sounds like a harsh accusation against "version oriented" tools.


Working with config-mgmt environment looks a bit like this:
-we start from an identified sets of files or configuration.
-we do some work on our session.
-we froze our session which could now become a new baseline.

In an ideal world, each steps like this should start from a known and
historical configuration. By "historical", i mean that this start
configuration is also the end point of an earlier step. With "direct
selection" of individual elements throw a "config-spec", we can
construct combinations of elements that have never exists together by
the past. This coherency problem could be solved if we only allow direct
inheritance (and merge/copy) for creating new configurations.

Tools that i call "version oriented" are using two identifications
systems:
-versions for identifying individual elements with (branch,revision)
-configurations for identifying sets of (element,version), namely "tags"
in CVS or "labels" in ClearCase. This second identification system is
based (or stacked) on the first one: it's a "bottom up" approach. Each
element has it's own baseline. This implies that direct selection can be
done at "element level".

With a "bottom up" approach, we directly identify "configurations" or
"change sets". Then, we are able to deduce versions for each files. We
use only one identification system instead of two. This is smarter
beacuse we don't need to have relationships between two systems and also
because the main purpose of software configuration management is to
*identify* software component. Using configurations as the
identification unit is more natural.

As explain above, direct selection could lead to inconsistencies. The
"granularity" of baselines is the level at which we can do direct
selection. In this second approach, "direct selection" are possible at a
"VOBS" or at a "Computer Software Component Item" level but not at
"individual element" level. "Version oriented" tools does not guaranted
this internal consistency inside a CSCI.

regards,

j.


--
Jérôme de Vivie

[Jerome de Vivie]

erratum:
With a "bottom up" approach, we directly identify "configurations" or
^^^^^^^^^^^
"top down"


--
Jérôme de Vivie

[Kevin Cline]

mmartincm@yahoo.ca (Martin) wrote in message news:<864159ba.0307060650.8e57864@posting.google.com>... I was wondering if there is a way to quickly test a new config. spec in clearcase to ensure ALL elements in a VOB are picked up by the rules in the spec. Basically, I like to ensure that the rules I specify do account for all elements in a VOB and no elements are left out when I go from an old config spec to a new one I create. Does a recursive "ls" on VOB followed by doing a count on the result of "ls" an option or is there a better way?

How complex do your config specs get? If they're getting so
complicated that you can't verify them by inspection, maybe you should
reconsider your development process.

Also, you rarely want ALL the elements in the VOB. Things change over
time -- old files are no longer needed, and new files are created.

[David Masterson]

>>>>> Martin writes:
I was wondering if there is a way to quickly test a new config. spec in clearcase to ensure ALL elements in a VOB are picked up by the rules in the spec. Basically, I like to ensure that the rules I specify do account for all elements in a VOB and no elements are left out when I go from an old config spec to a new one I create.
Does a recursive "ls" on VOB followed by doing a count on the result of "ls" an option or is there a better way?

Kind of a strange request as there are times that you want the
config-spec to "hide" elements. However, you might try comparing the
results of the following commands:

* count visible items in a VOB

cd /vobs/<VOB>
find . -print | wc -l

* count elements in the VOB

cd /vobs/<VOB>
cleartool find . -all -element 'version(/main/0)' -print | wc -l

I haven't tested that, but that might have a problem if you have
(symbolic or hard) links in your VOB (either private or ClearCase).

--
David Masterson David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer Synopsys, Inc.
Software Engineering Sunnyvale, CA

[Koushik Banerjee]

"Kevin Cline" <kcline17@hotmail.com> wrote in message
news:ba162549.0307090712.758fee1f@posting.google.com...
: mmartincm@yahoo.ca (Martin) wrote in message
news:<864159ba.0307060650.8e57864@posting.google.com>...
: > I was wondering if there is a way to quickly test a new config. spec
: > in clearcase to ensure ALL elements in a VOB are picked up by the
: > rules in the spec. Basically, I like to ensure that the rules I
: > specify do account for all elements in a VOB and no elements are left
: > out when I go from an old config spec to a new one I create.
: >
: > Does a recursive "ls" on VOB followed by doing a count on the result
: > of "ls" an option or is there a better way?
:
: How complex do your config specs get? If they're getting so
: complicated that you can't verify them by inspection, maybe you should
: reconsider your development process.
:
: Also, you rarely want ALL the elements in the VOB. Things change over
: time -- old files are no longer needed, and new files are created.

Rightly so. What are the branching and SCM process you follow? I never
heard or thought, that someone needed to set a config_spec in accordance
with what files he wanted in the view. It is the other way round, you
set the config_spec, and expect relevant elements to be visible. These
questions would arise when you are not sure of what is going around.
I would suggest that you sit down and note what is the development process
you are following and you can yourself come up with a config_spec that
matches your requirement. You should never think of looking at individual
fies to verify your config_spec, that will mean serious trouble. Maybe
you can put down your config_spec and everyone around can help you better.

Koushik

[Marc Girod]

>>>>> "MCM" == Martin <mmartincm@yahoo.ca> writes:

MCM> I was wondering if there is a way to quickly test a new config. spec
MCM> in clearcase to ensure ALL elements in a VOB are picked up by the
MCM> rules in the spec. Basically, I like to ensure that the rules I
MCM> specify do account for all elements in a VOB and no elements are left
MCM> out when I go from an old config spec to a new one I create.

Just to get something concrete to chew, and e.g. see what files you'd
really want to hide, what about this:

ct find -a -ele '!created_since(today)' -nxn -print | sed -e 's/\(.*\)/ls \1/' | cleartool | grep 'no version selected'

--
Marc Girod P.O. Box 323 Voice: +358-71 80 25581
Nokia NBI 00045 NOKIA Group Mobile: +358-50 38 78415
Takomo 1 / 4c27 Finland Fax: +358-71 80 61604

[Marc Girod]

>>>>> "MG" == Marc Girod <girod@shire.ntc.nokia.com> writes:

MG> ct find -a -ele '!created_since(today)' -nxn -print | sed -e 's/\(.*\)/ls \1/' | cleartool | grep 'no version selected'

Sorry... use /ls -d \1/ to avoid navigating the directories.

--
Marc Girod P.O. Box 323 Voice: +358-71 80 25581
Nokia NBI 00045 NOKIA Group Mobile: +358-50 38 78415
Takomo 1 / 4c27 Finland Fax: +358-71 80 61604