views:

1209

answers:

3

I'm a configuration manager and I'm working on Windows and UNIX environments. Currently, I have to create the views by myself for the developers and QA engineers. Is there any better approach?

Thanks.

A: 

Are the developers and QA engineers incapable of creating the views themselves? If so, some education (of the developers and QA engineers) is in order.

At work, we create our own working views. This is the script I use. By default, I request it to create a view such as bug129201 and it creates a view with my username and the host as part of the name: bug129201.jleffler.black (where black is my main machine). The view storage comes from the current directory unless I specify an alternative location (which I almost always do):

newview -p /work5/atria bug129201

The script takes a '-x' option to avoid the extended name; in that case, it creates a view (or views) with precisely the command-line tag. Also, by convention, 'ct' is not the antique Unix 'call terminal' program but an alias for 'cleartool' (or, in my case, a shell script that executes the cleartool program).

I can then set the config spec to whatever I need at the time. I also dispose of views quite quickly, to ensure that they don't accumulate unwanted debris.

#!/bin/ksh
#
#   @(#)$Id: newview.sh,v 1.8 2008/03/14 23:56:28 jleffler Exp $
#
#   Create a new view

usage(){
echo "`basename $0 .sh`: [-x] [-p path] view-tag" >&2; exit 1
}

umask 002
xflag=yes
path=`pwd`
while getopts xp: option "$@"
do
    case "$option" in
    p)  path="$OPTARG";;
    x)  xflag=no;;
    *)  usage;;
    esac
done

((x=OPTIND-1))
shift $x

[ $# -eq 0 ] && usage

umask 0

if [ $xflag = yes ]
then extn=$LOGNAME.`uname -n`
fi

for view in $*
do
    if [ $xflag = yes ]
    then
        # Check whether user added the extension already and forgot to
        # use -x option.
        case $view in
        *.$extn)    : OK;;
        *)          view=$view.$extn;;
        esac
    fi
    ct mkview -tag $view $path/$view.vws
done
Jonathan Leffler
+1  A: 

Yes: script the ClearCase view creation or explain them the mkview usage. Each user can then create is own view.

Create views is definitely not the role of a configuration manager.

1/ Determine a view naming convention

  • username_viewPurpose: non-UCM dynamic view
  • username_viewPurpose_snap: non-UCM snapshot view
  • username_streamname: UCM dynamic view
  • username_streamname_snap: UCM snapshot view

I would recommend all-minuscule case for the view names.

I really recommend always having the username included (as a prefix) in the name of a view. It is so much easy to manage/administer when you know who own the view without having to "ct lsview' it.

2/ Determine a view storage convention

  • either one central view storage, with a common storage name, or a common UNC path
  • or one view storage per developer desktop.

I use the second convention, because I consider their view as transient spaces for them to create / delete / recreate as they need.

3/ "empower" the user

  • Make a script (like Jonathan's one, but with a little more options, and able to work for Windows or Unix)
  • Describe the mkview command in a wiki page

I actually use the second convention, because each user can quite easily type a mkview and take into account his/her environment details (Windows/Unix, central storage/local storage, ...)

You also need to teach them how configure their config spec (even in UCM), in order to:

  • not select "lost+found" directories (useful when merging in UCM)
  • not select anything not already selected by previous config spec rules, meaning adding if needed a 'element /aVob/* -none' (useful in snapshot view in order to not have many empty directories)
VonC
A: 

I think that the easiest and most convenient way is to use a new ClearCase add-on - "ClearEnv", which automatically does it for you. Check here: http://gomidjets.com/ClearEnv.html

You can also to control the methodologies by using this add-on.

BR,

Tamir Gefen

CM and ALM

GoMidjets - Automate Your Advantage