From shannon@datsun Fri Nov  1 19:14 PST 1991
Date: Sat, 2 Nov 91 03:13:16 GMT
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet is available!
Content-Type: text
Content-Length: 4112
X-Lines: 130
Status: RO

Avocet is now available for use.  It's still very much a pre-alpha
version (in terms of feature-content; stability of the few features
that are there looks very good), so your feedback and patience are very
important!

This is a quick introduction to how to use Avocet under an NSE
integration environment.  There are only four commands you'll
normally need to use:

	nsebringover
		This is a combination of the NSE aquire, resync, and append
		commands.  There is also a "bringover" command that works
		between Avocet workspaces.

	nseputback
		This is the equivalent of the NSE reconcile command.  There's
		also a "putback" command that works between Avocet workspaces.

	resolve
		This is the equivalent of the NSE resolve command.  It
		will invoke fileresolve for you.

	activate
		This is a simple shell script I wrote, not part of Avocet
		itself.  It's similar to the NSE activate command in concept,
		but all it does is set some environment variables and simple
		things like that.  You can do all this yourself, but we
		encourage you to use the script because we'll make changes to
		the script to make things even easier to use in the future.

In addition, there's one other command you might use occasionally:

	workspace
		This allows you to discover information about an Avocet
		workspace.  (A workspace is analogous to an NSE environment.)

There are man pages for all these commands (except activate).  The
binaries and man pages are located in:

	4.1:	dunk:/usr/avocet
	5.0:	dunk:/opt/avocet




Here's a simple example using Avocet to create a child workspace of
an NSE environment.  We'll use the mailx command as an example.  We'll
be doing all this on a machine running 5.0, with no use of the NSE at
all!

First, set up your environment to get at the Avocet binaries.

	$ su
	# mkdir /opt/avocet
	# mount -F nfs dunk:/sdet/5.x.avocet /opt/avocet
	# exit
	$ PATH=$PATH:/opt/avocet/bin
	$ MANPATH=$MANPATH:/opt/avocet/man

Next, create a workspace and fill it with the files you need.

	$ nsebringover -p sysint@andrewr -w ~/mailx usr/src/cmd/mailx

Note that Avocet only brings over the source files.  You can name
individual files or directories (implying all source files under the
directory).  A local customization I made allows it to know to
bringover the various higher-level Makefiles that will be needed.
This should work for you when bringing over cmd or uts directories;
in other cases you may need to explicitly specify the additional
Makefiles.

Activate the workspace and do some work.  (Note that activate creates a
sub-shell.)

	$ activate ~/mailx
	/home/datsun/shannon/mailx

The activate script cd's us to the root of the workspace so we need to
cd down to where our source is.  (Note that there's no tfs or anything
like that involved here.)

	$ cd usr/src/cmd/mailx
	$ sccs edit main.c
	$ vi main.c

Here we edit, test, and debug our changes.

	$ sccs delget main.c

Now it's time to resync with the parent.

	$ nsebringover usr/src/cmd/mailx

If there were any conflicts we resolve them.

	$ resolve

After testing and debugging our merges, we're ready to reconcile our
changes back to the parent.

	$ nseputback usr/src/cmd/mailx

That's it, get out of our activated workspace!

	$ exit


This is a very simple procedure for very simple changes.  There are a
number of limitations which we don't expect to impact most people:

1.  We assume that using the native compilers, libraries, and include
    files on your 5.0 machine is "good enough" to build and test our
    work.  We'll relax this restriction eventually, but for now this
    is a limitation.  Of course, in the long term using the native
    stuff is not good enough, so expect changes here.

2.  You can't rename or delete files in an Avocet workspace.  Also,
    bringover (resync) won't bring down any renames from the parent.
    We expect to remove this latter limitation very shortly.

3.  Just to be sure you got it, don't rename or delete source files
    in an Avocet workspace!

If you have any questions or problems, let one of us know.

Enjoy!

	Bill Shannon
	Claire Giordano
	Tadd Ottman

From shannon@datsun Thu Nov  7 23:47 PST 1991
Date: Thu, 7 Nov 91 23:32:45 PST
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #1 - more tips
Content-Type: text
Content-Length: 2488
X-Lines: 56
Status: RO

There's a few things people have tripped over that were not explained
well (or at all) in my previous message.


In order to use nsebringover on a 5.0 system, you must have an
/etc/auto.nse file that contains a line like this:

+auto.nse

This is now explained in the nsebringover man page.  (If you have your
own /etc/auto.master file, it must reference /etc/auto.nse.)


When using nsebringover (or bringover), the file and directory names
specified must either be absolute pathnames that name files in the
source or destination workspaces, or they must be relative pathnames
which will be interpreted relative to the root of the workspace.

For example, in the command from my original message

	$ nsebringover -p sysint@andrewr -w ~/mailx usr/src/cmd/mailx

the relative pathname "usr/src/mailx" is interpreted relative to the
root of the workspace.  For an NSE environment, the root is the "real"
root (/) when the environment is activated.  For the Avocet workspace,
the root is the directory that names the workspace, "~/mailx" in this
case.

If instead we had used the the pathname "/usr/src/cmd/mailx", Avocet
would complain because that pathname is not under either workspace;
it's not under ~/mailx and it's not under /nse/br.mumblefritz/vcs.

The simple rule when using nsebringover is to use the same pathname
you would use if you were in the activated NSE environment, but leave
off the initial "/".  When using nsebringover you'll always want to
specify a pathname that starts with "usr/src/".


The NSE provides a shorthand (":") that means "everything in the
environment".  Avocet doesn't currently provide this, but it is being
added.  In the mean time, you'll usually want to explicitly specify
what subset of usr/src you want to bringover or putback.  In some
cases, such as in the i-mt5 environment, the NSE environment might
only contain a subset of all the system source.  If you want to bringover
or putback everything in that NSE environment, you could specify
either "usr/src" or just ".".  The disadvantage of specifying just "."
is that Avocet might spend a lot of time looking through the /proto
area in the NSE environment, only to find that there are no source files
there.


The nsebringover man page didn't exist at the time of my original
message, but it's there now.  It contains lots of useful information.

In addition, the Avocet "10 pager", which is a relatively high level
description of Avocet, is in the doc directory on dunk:/sdet/*.avocet/doc.

From shannon@datsun Fri Nov  8 15:50 PST 1991
Date: Fri, 8 Nov 91 23:49:20 GMT
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #2 - NSE <-> Avocet considerations
Content-Type: text
Content-Length: 1210
X-Lines: 29
Status: RO

There are a few considerations you should keep in mind when
using Avocet with an NSE environment.


First, Avocet doesn't obey any of the NSE environment locks.
Avocet will lock with itself so that, for instance, two nseputbacks
can't occur to the same NSE environment at the same time, but
Avocet won't lock against NSE operations happening at the same
time as Avocet operations.

This will rarely be a problem for nsebringover, but it is important
to coordinate nseputbacks with NSE reconciles.  One way to do this
is to use the NSE environment locks; be sure to acquire the NSE
lock before doing an nseputback.


Second, after an nseputback, none of the changes will be available
to other NSE children environments until a preserve is done in the
parent environment.  An NSE reconcile will do this preserve automatically,
but nseputback requires you to do it by hand.  Because of this, it is
generally simpler to not mix NSE children and Avocet children of the
same environment.  If you do mix, you'll need to do a preserve when
you want to make the changes integrated with Avocet available to the
NSE children.



Needless to say, neither of these issues are problems when using a
pure Avocet environment.

From shannon@datsun Fri Nov  8 16:31 PST 1991
Date: Sat, 9 Nov 91 00:31:28 GMT
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #3 - new Avocet release
Content-Type: text
Content-Length: 2363
X-Lines: 51
Status: RO

A new release of Avoet has been installed on dunk:

	4.1:	dunk:/usr/avocet
	5.0:	dunk:/opt/avocet

Here's the writeup from the Avocet group describing the changes in
this new release:

This release includes several new features:

1) Access control.  When a workspace is created, it is given an
   access control file in the avocet directory.  This file provides
   control over who can bringover and putback to and from the workspace,
   who can delete the workspace, etc.  Existing workspaces don't have
   an access control file so, as bringover and putback encounter these
   workspaces, they will be given a default access control file.

2) An undo command.  Bringover and putback make backup copies of
   files before they update them.  The undo command will restore the
   backup copies and undo the effects of the bringover or putback.
   There is just one level of undo, that is, only the most recent
   bringover or putback command can be undone.

3) Bringover and putback now have a -a (all) option.  This option
   tells the commands to operate on all of the child workspace.
   Bringover and putback maintain a file ("args") in the avocet 
   directory that contains a description of all of the workspace.  
   For example, if you have brought over five different directories, 
   then the args file will contain the name of the five directories. 
   After the initial bringover, putback -a and bringover -a can be
   used.

4) An nsegetsdot command.  This command is useful for people using
   nsebringover and nseputback.  It is an NSE command that can be used
   to make sure an NSE environment has all its s-files.  For nsebringover
   to work properly, an NSE env must have all its s-files.  Since this
   is an NSE command it is available for 4.x only.

Bug fixes include:

1) Bringover-create -n was failing because it was trying to chdir
   to the workspace that would be (but was not) created.  Reported
   by Bill Shannon.
2) Bringover-create deletes the newly created workspace if it is unable
   to bringover any files.
2) Man pages for nsebringover and nseputback.
3) Bringover and putback now catch signals and clean up their locks.
4) Bringover and putback now complete their first pass to find all
   potential errors.  Reported by Mike Federwisch.
5) Added a -f (force) option to workspace reparent.  Requested by
   Mike Federwisch.

From shannon@datsun Tue Nov 12 00:59 PST 1991
Date: Tue, 12 Nov 91 00:58:39 PST
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #4 - performance
Content-Type: text
Content-Length: 1071
X-Lines: 43
Status: RO

I did some simple, non-scientific benchmarks of nsebringover.  I did
an nsebringover of usr/src/uts from i-mt5 to my 5.0 machine and to my
4.1 machine.  In both cases the files were brought over to a local
disk.  The benchmark environment was not controlled in any manner,
and the results are very likely unrepeatable.  Here's what I got:

4.1
    initial bringover
	30:27.4 real
	 4:10.1 user
	 9:23.2 sys

    null resync bringover
	15:15.6 real
	 1:02.9 user
	 6:01.3 sys

5.0
    initial bringover
	37:17.3 real
	 3:33.7 user
	15:04.4 sys

    null resync bringover
	22:40 real
	 1:16 user
	10:52 sys

There were 1735 files involved, 47MB (SCCS files and clear files).

In addition, Tadd did a bringover of all of usr/src:

The bringover of all of usr/src for the phobos workspace finished on
dunk, a 4/390 running 4.1.1.  Here is the summary and time:

Summary:
        New files: 11495

1139.7u 2554.0s 2:18:48 44% 0+1120k 34256+109357io 20604pf+0w


That 2 hour bringover compares to something like 8 hours or more
for an acquire of all of SunOSint using the NSE.

From cmh@kipling  Mon Nov 18 17:13:26 1991
Date: Mon, 18 Nov 91 17:10:37 PST
From: cmh@kipling (Claire Hayes Giordano)
To: cal-dev@benet
Subject: Avocet update #6 -- SunOS workspace hierarchy
Cc: sdet@plunge, cal-cteam@benet
Content-Length: 3089
X-Lines: 86
Status: RO


The train workspace is located on:

	/net/dunk/sdet/train

The workspace roadmap for future ON development is as follows:

	((--------------------------))
	(( SunOSint a.k.a. Callisto ))
	((--------------------------))
		      |
		      |
	[[--------------------------]]
	[[ intchild a.k.a. buffer   ]]
	[[ /net/dunk/sdet/intchild  ]]
	[[--------------------------]]
		      |
		      |
	[[--------------------------]]
	[[          phobos	    ]]	
	[[ TBD... in B15 somewhere  ]]
	[[--------------------------]]
		      |
		      |
	[[--------------------------]] 
	[[	    train           ]]
	[[   /net/dunk/sdet/train   ]]
	[[--------------------------]]


((--))	NSE Environment

[[--]]	Avocet Workspace 

|
|	parent/child relationship

	... Where to work:

Anyone wanting to do Callisto bug fixing for Jupiter should continue 
work under one of the cal-big7 NSE i-team envs that are children of 
SunOSint.  Coordinate with the i-team leader with regard to policies.

Anyone wanting to contribute to Phobos development for Mars, an SMCC 
managed release, should work under the Phobos workspace.  Details 
regarding integration to Phobos will be handled by the SMCC group.  
Send mail to phobos-int@crissy with questions about Phobos integration.

Anyone wanting to contribute to Titan development for Saturn should 
work under the Train workspace.  Details regarding integration to the 
Train will be handled by the OST (Ostech) integration group, a.k.a.
cal-int@benet.  Titan integration and consolidation policies are 
still being worked.  For now, feel free to bringover a child and 
start your development.

	... Things to know:

	(1) We are going to be integrating some Makefile changes 
into the top Avocet workspace (the buffer) in the near future.  These 
Makefile changes will support native builds of ON sources on 5.0 
machines.  We will let you know when this happens.

	(2) Although avocet reparenting allows you to reparent between 
any Avocet workspace, there will be OST policies about the direction 
in which one can reparent.  Reparenting between workspaces integrating
into the same release, such as sibling i-team workspaces, will be 
allowed.  However, as you try to reparent between different releases, 
reparenting will ONLY be allowed from release N to release N+X.  Thus, 
you can reparent from Phobos to the Train, but not vice-versa.

Thus, if in doubt about which release to work under, work under 
the earliest release.  In the example above, work under the Phobos 
workspace, since ideally all Phobos changes are absorbed into the 
Train anyway, and you can reparent later if necessary.

	(3) Since the NSE doesn't handle sccs file histories in the way
that one might like, OST policies will also restrict reparenting an
Avocet workspace from under the NSE i-team environments to the new
post-Callisto Avocet hierarchy.  Just don't do it.  If you have an 
Avocet workspace under i-ddifix, don't expect to reparent it to the 
Train.  

	(4) We have named SunOSint's sccs file history as the history 
that we will carry into development of future releases.



From shannon@datsun Tue Nov 19 00:47 PST 1991
Date: Tue, 19 Nov 91 00:18:05 PST
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #5 - native kernel builds
Content-Length: 1010
Content-Type: text
X-Lines: 21
Status: RO

	[newer note: this is now an obsolete approach]

Doing native kernel builds on 5.0 requires a little trickery.
The Makefiles are currently set up to do the builds on a 4.x
machine.  Different people have been using different techniques
to get around this.  I've come up with what I think is a simple
way to deal with this.

The kernel Makefiles explicitly call /usr/bin/cc when they need
the native compiler.  They also pass arguments that are recognized
by the 4.x cc command, but not by the 5.0 cc command.  Since there
is no /usr/bin/cc program on 5.0 (it lives in /usr/ccs/bin), I've
created a simple shell script to replace /usr/bin/cc which understands
the few 4.x-specific options the kernel Makefiles use and translates
them to the 5.0 equivalents.

I've placed my /usr/bin/cc shell script in the 5.0 Avocet bin directory
as usr_bin_cc.  If you're building the kernel on your 5.0 machine, you
should copy this shell script to /usr/bin/cc.

If you have any problems with this shell script, let me know.

From cmh@kipling  Mon Apr  6 11:54:07 1992
Date: Mon, 6 Apr 92 11:49:28 PDT
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: Avocet update #8 -- Reparenting between callisto and phobos
Content-Length: 1356
X-Lines: 32
Status: RO


Recently as some developers have transitioned away from Callisto
development and toward Phobos development, they have wanted to
reparent their avocet workspaces. 

There is a policy for developers of the OsNet source base that advises
developers **NOT** to reparent a workspace currently a child of the Callisto 
hierarchy over to the Phobos or Titan source hierarchies.

Note that any avocet child, grandchild, or greatgrandchild in the
Callisto hierarchy has this restriction.

The avocet product allows you to reparent any avocet workspace,
assuming you have the access control to do so.  Hence this policy is
not the result of an avocet limitation, but rather it's the result of
Nse limitations.  

If you try to reparent between Callisto and Phobos/Titan, the sccs file 
histories will not match due to the way the Nse manipulates sccs 
file histories.  You will end up with myriads of conflicts and even 
if you resolve these conflicts, a putback would place the incorrect 
sccs file history into the parent workspace and would cause problems
for many other developers.  Please do *not* do this.

This is a short term restriction that we will leave behind us as
we leave the Nse behind us.

If you have any questions or concerns, let me know.

FYI:
	Callisto:  OsNet portion of Jupiter consolidation 
	Phobos:    OsNet portion of Mars consolidation

From msw@polyslo Wed Apr 22 11:13 PDT 1992
Date: Wed, 22 Apr 92 10:56:03 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet update #11 -- Avocet File List Generators (FLG's)
Content-Length: 6746
Content-Type: text
X-Lines: 237
Status: RO


We have introduced a new default directory file list generator,
def.dir.flg, which can operate on input provided by files populated
among the ON source tree called req.flg and inc.flg.  These file list
generators (flg's) are meant to simplify the bringover process for
subsets of the ON source tree.  To build usr/src/stand/kadb you need
900+ source files, but only a small portion of them reside under the
usr/src/stand/kadb directory.  To make the bringover of
usr/src/stand/kadb and all of its supporting source files an atomic
operation we have introduced two new file list generators into the ON
source base.  They are:

	inc.flg:  List those files which do not reside under the
		current directory but are required in order to build
		the current directory.  For example, when you build
		usr/src/stand/kadb it requires several header files
		from usr/src/uts/common/*/*.h.  It would be the
		inc.flg's responsibility to list these files so that
		avocet can find them during a bringover or putback
		operation.

	req.flg:  List those files which are required if the specified
		directory is in the path of the directory you are
		bringinging over (bringover) or putting back
		(putback).  For example, there is a req.flg in the
		usr/src directory which lists Makefile.master.  When
		you perform a bringover on the usr/src/stand/kadb
		directory the req.flg would be executed and list
		usr/src/Makefile.master.


When a bringover or a putback operation is performed on a directory by
avocet our def.dir.flg scripts will generate a file list by doing the
following:

	1) Search in the current directory and every directory above
	   it to find a req.flg.  If one is found execute it to
	   generate a list of files.

	2) Search the current directory and every directory below it
	   for inc.flg's.  Execute each one that is found for an
	   additional list of files.

	3) Search the current directory and every directory below it
	   for all SCCS files, each of these is added to the file
	   list.  (Note: this is the default behavior)


These new flg's (req.flg & inc.flg) are now part of the ON source
base and under SCCS control.  Whenever you bringover a portion of
the ON source base the matching flg's will also be brought over as
part of the source.

So, now that we have introduced these new flg's when you issue
bringover's on specific directories you may get more than you expected.
For example, when you issue a bringover on the stand/kadb directory
you will not only get the source under stand/kadb but all the source
that is required to build the stand/kadb directory.  Some of the
additional directories you will get are:

	stand/kadb
	stand/lib
	uts/sunmmu
	uts/srmmu
	uts/common/sys
	uts/common/vm
	uts/common/os
	uts/common/rpc
	uts/common/nfs
	uts/adb
	cmd/adb/sparc
	...


We have introduced inc.flg's for the following directories components:

	usr/src/stand/kadb
	usr/src/stand/boot

And we have introduced req.flg's for the following directories:

	usr/src/req.flg
	usr/src/cmd/req.flg
	usr/src/lib/req.flg
	usr/src/ucbcmd/req.flg
	usr/src/ucblib/req.flg
	usr/src/uts/req.flg


Before I go into more detail there are a couple of points
I would like to make:
   
   1) The flg concept is still evolving in the avocet group and we can
      expect a new def.dir.flg from the avocet group in the future.
      When this happens we will have to modify what we have to fit
      under there new model (although it should only require minimal
      modifications).

   2) There is room for futher development on the inc.flg's and the 
      req.flg's.  If anyone would like to introduce some more of these
      into the source base I would very much like to help.  Just shoot
      me (msw@eng) an e-mail and we can put something together.



WARNING:  The following goes into a little more detail on how exactly
   	  the inc.flg's and req.flg's work.  You only need to read
	  this if you are interested.


Here is a practical example of how these are used in the ON source
base.  Given the following file structure:



			usr/src/
			   |
			   |
	     _____________/-\___________________
	    /	     /		 \		\
	 req.flg   uts/		stand/		 */
		    /		  |
		   */	      ___/-\________________
			     /		  \	    \
			   boot/	 kadb/	    */
			    /		   \
			 inc.flg	   inc.flg



When the following command 'bringover usr/src/stand' is performed avocet
is going to execute the following scripts and commands to generate
the list of files that will be brought over:

	usr/src/req.flg 
		- list all files that are required if you include usr/src
		  in your path - Lists Makefile.master	

	usr/src/stand/boot/inc.flg
	   	- list all files not under usr/src/stand/boot that
		  are required to build usr/src/stand/boot.
		
	usr/src/stand/kadb/inc.flg	
		- list all files not under usr/src/stand/kadb that are
		  required to build usr/src/stand/kadb.

	find usr/src/stand -name "s.*" -print
	  	- lists all SCCS files under usr/src/stand.  
	


For additional information here is what a couple of the above flg's
actually look like:

::::::::::::::
usr/src/req.flg
::::::::::::::
#!/bin/sh

#
# Any directory containing usr/src in it's path must have
# usr/src/Makefile.master.

echo_file usr/src/Makefile.master

::::::::::::::
usr/src/stand/kadb/inc.flg
::::::::::::::
#!/bin/sh

#
# find_files(pat,dirs...)
#
# pat   = pattern to pass to find
# dirs  = space separated list of directories for find to visit
#
find_files() {

   	pat=$1
   	shift

	for dir in $*
	do
	   if [ -d $AVOCET_WS_ROOT/$dir ]; then
	      find $AVOCET_WS_ROOT/$dir -name "$pat" -print | grep "/SCCS/s."
	   fi
	done

} # find_files()


echo_file() {
	#
	# Check to make sure a file exists, if it does then
	# echo it out.
	#
   	if [ -f $AVOCET_WS_ROOT/$1 ]; then
      		echo $1
   	fi
} # echo_file()


#
# Find all of the header files required for the build
#
find_files "s.*.h" \
           usr/src/uts/sunmmu\
           usr/src/uts/srmmu\
           usr/src/uts/common/sys\
           usr/src/uts/common/vm\
           usr/src/uts/common/os\
           usr/src/uts/common/rpc\
           usr/src/uts/common/nfs\
           usr/src/uts/sun\
           usr/src/uts/sun4/sys\
           usr/src/uts/sun4c/sys\
           usr/src/uts/sun4m/sys\
           usr/src/uts/sparc/sys\
           usr/src/cmd/adb/sparc\
           usr/src/stand/sys\
           usr/src/head

#
# These are all of the supporting directories
#
find_files "s.*" \
           usr/src/cmd/adb/sparc\
           usr/src/stand/lib\
           usr/src/uts/adb\
           usr/src/uts/sun/promif\
           usr/src/cmd/adb/common


echo_file usr/src/lib/Makefile.lib
echo_file usr/src/cmd/Makefile.cmd
echo_file usr/src/cmd/Makefile.targ
echo_file usr/src/uts/Makefile.uts

From msw@polyslo Fri May  1 17:02 PDT 1992
Date: Fri, 1 May 92 16:42:33 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet update #12 - ws
Content-Length: 3260
Content-Type: text
X-Lines: 93
Status: RO


ws is a new tool that will help with the maintaining the new avocet
workspaces, it is a very light weight mechanism meant to help
maintain avocet workspaces.  It would be used similarly to activate
under NSE, except that it is much more light weight and does not
introduce any of the bottlenecks that NSE did (TFS,...).

Here's a list of Q & A's that will hopefully answer most of your
questions:

>> Question:  What is ws?

ws is a script that helps to configure your environment for builds
of the ON source base in an Avocet workspace.  It is only a script
that sets up your environment variables for a ON build and then 
invokes a shell.

>> Question:  Who should use ws?

Anyone doing a build of the ON-Source base in an Avocet workspace.  
This would include everything from a build of phobos, titan,
and onwards.

>> Question:  Why should you use ws?

ws does several things, first it specifies which PROTO areas you will
build against.  It is now possible with ws to configure your workspace
to build against a hierarchy of PROTO areas.  When you build against a
PROTO area that is where you will find many of your include files and
the libraries you build against.  By default ws will build
against the PROTO area of your current workspace and then, if your
parent is an avocet workspace, against your parents PROTO area.
Lastly the search will terminate on your native machine which you
are building on.

Next ws will configure your ROOT (your install destination),  your SRC,
and your PATH environment variables, ROOT by default will point to your
current workspaces PROTO area.  Your PATH will have the Construction
set (more details on this to follow), if available, prepended to it on
a 5.x machine.  Note:  If your path is set by .cshrc then any
changes that ws applies to your path will be undone when the new
shell is invoked.

ws also lets you configure all of the above.  There is a file
in your avocet workspace ($AVOCET_WS/avocet/sunos/protodefs) that
you can use to set default values for your workspace.  ws will
create this file on the first invocation on a workspace and will
re-read it on each subsequent invocation to configure itself.


>> Question: How do I invoke it?

Here is a sample invocation of ws:

polyslo 364: ws /net/amtrak/build/titan_uts

Workspace ($AVOCET_WS) : /net/amtrak/build/titan_uts
Proto area ($ROOT)     : /net/amtrak/build/titan_uts/proto
Root of source ($SRC)  : /net/amtrak/build/titan_uts/usr/src
Prepended to PATH      : /opt/onbld/bin
Current directory (PWD): /net/amtrak/build/titan_uts

polyslo 1:

>> Questions: What does WS do?

WS configures your environment for builds of the ON source tree,  it
does this by reading in some configurable values from the
avocet/sunos/protodefs files and then setting the following environment
variables:

	AVOCET_WS
	SRC
	ROOT
	MAKEFLAGS
	ENVCPPFLAGS{1-4}
	ENVLDLIBS{1-3}
	PATH

>> Questions: Where is ws

ws is distributed with the OS-Net avocet binaries.  They
are located on:
		dunk:/sdet/5.x/avocet/*

	[ see newer messages for current locations ]

>> Questions: Docs??

For more details about ws and how you can configure it please refer to
the ws(1) and protodefs(5) man pages under dunk:/sdet/5.x.avocet/man.

	[ see newer messages for current locations ]

From msw@polyslo Fri May  1 17:04 PDT 1992
Date: Fri, 1 May 92 16:45:51 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet update #14 - Construction Set -- updated
Content-Length: 3241
Content-Type: text
X-Lines: 95
Status: RO


There is now a Construction Set available for doing ON builds natively on
a 5.x machine, the construction set is available only for 5.x ON builds.
The construction set has three goals:

	1) To provide those tools which do not come with a 
	   regularly delivered package but are needed for an ON build
	   of the ON source tree (eg., rpcgen).

	2) To provide a stable location for those tools used by
	   the ON build which tend to vary in functionality (eg., rpcgen,
	   tic, zic, ...).  As it becomes required we will roll
	   specific version of the compilers into the construction sets
	   as the compilers start to vary.
 
	3) To provide a fixed set of tools that can be associated
	   with a specific release of the build (eg: you might need one
	   set for a phobos workspace and another set for a titan
	   workspace).

The construction set is available in package format and it can
either be pkgadd'd locally to your system or it can be NFS
mounted from a server.


Distribution:
-------------

To pkgadd the Construction Set to your local 5.x system do the following:

	# /usr/sbin/pkgadd -d /net/dunk/sdet/pkgs

Or to NFS mount the Construction Set to your local system:

	# mkdir /opt/onbld
	# mount -F nfs dunk:/sdet/onbld /opt/onbld

	[ see newer messages for current locations ]

Note:  	If you are not located in building MTV5 you should install the
  	construction set on an NFS server for general availability.


Mechanics:
----------

The directory structure below will support the construction set, where
VERS will change with the release of the construction set(1.0, 1.1,
...).

	/opt/onbld/VERS/bin/*
	/opt/onbld/bin -> VERS/bin

The use of the VERS will give us the ability to have multiple copies of
the construction set on a machine simultaneously.  This will provide
support for the possibility that you may need different copies of the
construction set on the same machine.  If you are working on different
revision levels of the ON source base, it might require that you have
different versions of the tools that come with the construction set (eg.,
rpcgen).

Lastly, there is support for the construction set within the ws
activation script.  ws performs a test for the construction set and, if
it is present, inserts the construction set into your PATH.  Also, by
using the capabilities of the ws protodefs file, you can associate
specific versions of the construction set with an Avocet workspace.
For example you could insert the following line into your protodefs
file for an avocet workspace:

	ONBLD_DIR=/opt/onbld/1.0/bin

This associates the 1.0 version of the construction set with your
specific workspace.  As other versions of the construction set becomes
available, you might edit protodefs to associate other versions with
your workspace.  If you make no entries in your protodefs file then ws
will insert /opt/onbld/bin into your PATH if it exists.  This symbolic
link will always point to the most current version of the construction
set.

For more info on the protodefs file and ws refer to the ws man page.

Contents:
---------

Presently the construction set contains the following files:

tic
zic
forth
tokenizer.exe
tokenize
rpcgen
cstyle
perl
	[some items have been since deleted or moved]

From msw@polyslo Tue May 19 10:02 PDT 1992
Date: Tue, 19 May 92 09:50:04 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet Update #15 - /ws automounter map
Content-Length: 859
Content-Type: text
X-Lines: 22
Status: RO


There is a new automounter map in the NIS maps (auto.ws) which gives
us a common space to access public ON-Source workspaces.  If you reboot
your system you should find the new maps under /ws.  The new
maps now contain the following workspaces:


/ws/phobos.INT	-	integration workspace for phobos(mars).
/ws/phobos.REF	- 	"golden source" workspace for phobos(mars).
/ws/ON1		-	OS-Tech workspace for integration into phobos.
/ws/ON2		-	DCT workspace for integration into phobos.
/ws/train	-	Titan (Solaris 4/93) workspace.

	[ old examples, but the concept is unchanged ]

These maps are fully populated in the EBB.Eng.Sun.COM domain already,
they are presently being pushed out to the DGDO.Eng.Sun.COM NIS
domain.

If you are not in either of the above NIS domains and you need access
to this map send me e-mail and I will extend the map to your NIS
domain.

From msw@polyslo Thu May 28 10:09 PDT 1992
Date: Thu, 28 May 92 09:39:07 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet Update #16 - sccsrm & deletion of files under Avocet
Content-Length: 1079
Content-Type: text
X-Lines: 34
Status: RO


Now that the new Avocet binaries have rename support we can now
do source code deletions under Avocet.  A file deletion under
an Avocet workspace is really just a special rename, you DO NOT
'rm' the file.  Instead we would like to follow this renaming
convention for file deletions:

   o The file should not be checked out.
   o You must rename both the 'clear' file and the 's-dot' file
   o Deleted files should follow this naming convention:

	.del-<file_name>-<month>-<day>

     So for file a.c you would do the following renames:

	file a.c   -> .del-a.c-May-19
	file SCCS/s.a.c -> SCCS/s..del-a.c-May-19


To help with this we have created a small utility (sccsrm) which will
do these operations for you.  sccsrm is to be used to do file deletions
under Avocet workspaces.  It can be used as follows:

	% sccsrm a.c

sccsrm is in the current Avocet release (dunk:/opt/avocet) and is
now available for use, there is also a short man page for sccsrm:

	dunk:/opt/avocet/bin/sccsrm
	dunk:/opt/avocet/man/man1/sccsrm.1

	[ see newer messages for current locations ]

_Mike_

From msw Fri Sep 25 16:12 PDT 1992
Date: Fri, 25 Sep 92 16:12:12 PDT
From: msw (Michael Walker)
To: osnet-sde@stufff
Subject: Avocet Update #17 - sccscp & sccsmv introduced
Content-Length: 1550
Content-Type: text
X-Lines: 48
Status: RO


We (the OsNet) group have introduced two new tools for help with
managing SCCS files in CodeMgr workspaces.  They are:

sccscp:

sccscp is to be used when you want to 'fork' a source file within
a CodeMgr workspace.  This is helpful when someone wants to 
fork a file off of the present source tree, yet keep the previous
SCCS history that has been built up in the file (eg:  copying
the usr/src/uts/sun4c/cgsix driver over to usr/src/uts/sun4f/cgsix).
sccscp uniquifies the SMID's as it copies each s-dot file.

It would be used as follows:
	% sccscp -r uts/sun4c/cgsix uts/sun4f/cgsix
	...

usage:	sccscp [-r] filename1 [ filename2...] target
	-r copy a directory and all of its files
	-g copy the sdot file, but do not sccs-get it
	-e copy most recent delta if file is currently checked out.
	-d debug mode
	
	*** Note - special thanx to the CodeMgr group for help
	    with sccscp.

sccsmv:

sccsmv is to be used to 'move' SCCS files around within a CodeMgr
workspace.  sccsmv will move both the clear files and the corresponding
s-dot files.

It would be used as follows:
	% sccsmv uts/sun4c/cgsix/Makefile uts/sparc/cgsix/Makefile
	...

usage: sccsmv filename1 [filename2 ...] target

Both of these commands have been installed under the current 
CodeMgr distribution - no action is required if you mount these
binaries off of dunk.

	dunk:/opt/teamware/bin/sccs{mv,cp}	5.x distribution
	dunk:/usr/teamware/sccs{mv,cp}		4.x distribution

	[ see newer messages for current locations ]

For further details refer to the corresponding man pages.

From cmh@kipling Mon Oct  5 13:38:47 1992
Date: Mon, 5 Oct 92 13:34:47 PDT
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: Avocet Update #18 - sccs help utility
Content-Length: 1314
Status: RO
X-Lines: 39


A number of people have recently encountered sccs error messages
while using the Codemgr tools.

In many cases, the sccs errors are caused by basic system problems 
which are easily and quickly solved, such as lack of write permissions.  

The sccs command provides a useful help utility which can be used
to retrieve more info regarding the problem, given the error code. 

This utility is called 'sccs help'.

You can distinguish an sccs error message from a Codemgr error
message by the distinctive all caps ERROR prefix that marks an 
sccs error message:

	ERROR: cannot create lock file (cm4)

Once recognized, you can provide the error code seen above in
parentheses as input to the 'sccs help' command:

	kipling% sccs help cm4

	cm4:
	"cannot create lock file"
	There are two known reasons why this can occur.

	1) Someone else is updating the SCCS file (or the p-file).
	   You'll have to wait until they're through, and try again.

	2) You do not have write permission in the directory where the
	   SCCS file resides.  If this is so, you are not allowed to
	   create any files (including the ``lock file'') in that
	   directory.

	If it is neither of the two reasons and the problem persists, 
	contact your Source Code Administrator (SCA).

See the man pages for sccs-help or help for more details.

From cmh@kipling Mon Oct  5 17:06:59 1992
Date: Mon, 5 Oct 92 17:06:11 PDT
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: Avocet Update #19 -- reparenting policies
Content-Length: 1255
X-Lines: 32
Status: RO


Although the Codemgr utility allows one to reparent a workspace to
another workspace without any policy restrictions,

	there are OsNet-specific policies regarding reparenting 
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

of which you should be aware:

1) ONLY reparent from an older release such as phobos to a
   newer release such as on493.  

   Do NOT try the reverse, since such action might introduce 
   on493-specific changes into phobos.

2) WHEN reparenting from phobos to on493, realize that if
   your putback preceeds the latest update from phobos-->on493
   update, you might introduce phobos changes other than your 
   own into on493 BEFORE the natural phobos-->on493 update.

   What this implies is that if you pass as arguments to putback only 
   specific files or only specific portions of the hierarchy, you 
   might break the on493 parent even though the tests passed in your 
   workspace.  

   Why?  Because the changes in the files you putback had logical
   dependencies on other "changed" files in your workspace which
   you did not putback.

   Heads-up.  Reparent with caution.  Use 'putback -n' and 'diff'
   to detect changes other than your own which you might accidentally
   putback after reparenting.

From tadd@b5mail Tue Oct 13 12:06:56 1992
Date: Tue, 13 Oct 92 12:05:56 PDT
From: tadd@b5mail (Tadd Ottman)
To: osnet-sde@stufff
Subject: codemgr update #20 - Construction Set -- updated
Content-Length: 1921
X-Lines: 39
Status: RO

  [ pbld and spawn are now obsolete because of pmake and work by Roger ]

Introducing pbld, spawn, install.bin, protolist, and protocmp:

	The construction set, which contains forth and other utilities
used for OS-Net builds, has been updated and extended.  It is primarily
available as the SUNWonbld package (version 1.3) obtainable from the
/net/dunk/sdet/pkgs/1.3 directory as SUNWonbld.  You may pkgadd this
new SUNWonbld package without pkgrm'ing the earlier version(s) on your
machine.  Secondarily, you may mount /sdet/onbld from dunk onto your
/opt/onbld directory.

	[ see newer messages for current locations ]

	Version 1.3 of the construction set package presents several
new utilities.  I am introducing pbld, a parallel-build script, with
a man page to describe it (/opt/onbld/man/man1/pbld.1).  The package
includes items used by or used with pbld, including Roger Faulkner's
spawn utility and Mike Walker's binary version of install (called
install.bin).  pbld and friends work together to build all OS-Net
source from scratch in 4 1/2 hours on a 4-way viking, 5 1/2 on a
2-way viking, and 13 1/2 hours on an SS2.  See the man page for
details.

	For calculating impact on packages, two new utilities are
introduced (documentation to follow).  These are protolist and protocmp.
They are tools for the gate keeper.  protolist lists the attributes of
files, directories, and other objects in your proto area; it functionally
replaces syslist for generating a list of ownerships and permissions
needed for specifying package definitions.  protocmp compares two lists
generated by protolist, thus revealing changes to the delivered product
and impact on packages.  (protolist calls str_format, which is also new
to the construction set.)

	If you need background information on construction sets and
the SUNWonbld package, see avocet update #14 in the avo_updates mail
folder in /opt/teamware/doc.

					Tadd

From tadd@b5mail Thu Nov 12 18:31:43 1992
Date: Thu, 12 Nov 92 18:23:30 PST
From: tadd@b5mail (Tadd Ottman)
To: osnet-sde@stufff
Subject: codemgr update #21 - construction set updated
Content-Length: 807
X-Lines: 19
Status: RO

	Version 1.4 of the construction set is available.  You may
pkgadd SUNWonbld from the /net/dunk/sdet/pkgs/1.4 directory or mount
dunk:/sdet/onbld on your /opt/onbld directory.

e.g.,	pkgadd -d /net/dunk/sdet/pkgs/1.4 SUNWonbld

	[ see newer messages for current locations ]

	Version 1.4 is smaller than 1.3.  Several utilities of use
only to gate keepers have been moved into a new SUNWongk package about
to be announced.  cstyle and the perl that it calls have been moved
out of the construction set and into the set of customizations we
applied to the recent teamware release.  Since several versions of
the construction set may be installed at once on a machine, there was
no point in having N copies of perl taking up space.

	Several updates and fixes have been applied to the pbld script.

					Tadd

From cmh@kipling Wed Nov 18 15:22:51 1992
Date: Wed, 18 Nov 92 15:18:32 PST
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: codemgr update #22 - AVOID sccs rmdel, fix and cdc
Content-Length: 531
X-Lines: 31
Status: RO


Remember...

	DO NOT USE sccs rmdel

	DO NOT USE sccs fix

	DO NOT USE sccs cdc

in your codemgr workspaces!!!!!

The codemgr sccsmerge functionality (aka smoosh) does not work well
when the above sccs commands have been invoked.  Avoid using these
utilities!  Recently an sccs rmdel caused needless confusion and wasted
cycles for developers and gatekeepers alike.

For a one page description of codemgr tips for getting started, see:

	dunk:/opt/teamware/doc/sde_start

	[ /shared/ON/teamware_docs/sde_start ]

Claire







  

From msw@polyslo Tue Feb 23 12:49 PST 1993
Date: Tue, 23 Feb 93 12:56:23 PST
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: codemgr update #23 -- hdrchk utility
Content-Length: 4202
Content-Type: text
X-Lines: 130
Status: RO


All,

A new hdrchk utility has now been added to the OsNet distribution
of TeamWare.  If you mount teamware off of dunk then no action
is required.  If you have a private copy of the OsNet teamware
you will have to copy the following file and symlink.


for 5.x hdrchk, see	dunk:/opt/teamware/bin/hdrchk  <symlink>
			dunk:/opt/teamware/OSNet/bin/hdrchk

for 4.x hdrchk, see	dunk:/usr/teamware/hdrchk  <symlink>
			dunk:/usr/teamware/OSNet/bin/hdrchk

	Here's what jek3 has to say about this new tool:


		   	 hdrchk

A new tool for checking conformance to standards has been added to the build
utilities.  It is a perl script called hdrchk which checks a header for
conformance to PSARC/1991/041.  Actually, it checks for a bit more uniformity
with respect to uniform formatting than is specified by 1991/041, but these
`nits' are not excessive and do increase the uniformity and percieved quality
of our headers.  1991/041 has also been refered to as KNF format.

hdrchk was written and debugged for the most part by Bill Shannon at my
request.  It seems to do a pretty darn good job of noting when something
isn't right but sometimes the diagnostic issued isn't exactly descriptive
of the problem.  I encourage constructive critisism but ask that it be
directed to me first so I can filter it before enlisting Bill's help.  (Who
knows, I might even learn Perl this way.)

All the exported headers under 1093 pass the hdrchk and cstyle tools with
the few exceptions noted below.  All the Makefiles which install headers have
been modified with the addition of a `check' target which currently applies
hdrchk and cstyle to all the headers in the directory (and recursively to
interesting subdirectories).  An individual file may be checked by entering
`make file.check'.  The Makefiles know about the exceptions and will pass
these files as well.
 
The exceptions are as follows:

head/assert.h:		[hdrchk]

			This file is required by ANSI-C to not be idempotent.
			Therefore the `end guard' is not the last thing in the
			file.  This is the way it must be and should not be
			fixed - ever! 

uts/sun/sys/devops.h:	[cstyle] devops.h: 296: line > 80 characters

			This file has a macro where the formal parameters to
			the macro are greater than 80 characters.  cpp (or
			the equivalent built into acomp) does not allow
			continuation line breaks in the formal parameter
			list.  This could be fixed by giving shorter names
			to the formal parameters, but the right fix is to
			fix cpp.

			There is a version of cstyle which allows this to
			be fixed with /* CSTYLED */, but this version seems
			to not be widely distributed.  When it is, this
			exception should be removed from the Makefiles and
			embedded in the header.

lib/libcurses/screen/term.h:
			[cstyle] Many `line > 80 characters'

			This file is generated by a complex ed script.
			Someday somebody who is really bored might fix this.

All rpcgen'erated files:

			There are several reasons these aren't checked at
			this time:

			1)  A silly error in rpcgen causes it to actually
			    generate cstyle errors.

			2)  The .x input files have more violations than I
			    care to deal with.  I want to get somebody who
			    knows more about these to fix them.

			3)  There seems to be good reasons for the headers
			    generated by rpcgen to not meet all the hdrchk
			    standards.  A special version probably needs to
			    be developed to check these.


A typical new header could be generated from the following template:

/*
 * Copyright (c) 1993 by Sun Microsystems, Inc.
 */

/*
 * Template for header files.
 *
 * This assumes the file is named <sys/foo.h>.  Don't forget to change
 * the _SYS_FOO_H symbol in all three places in this template to reflect
 * the real name of your header file.  Also note that this name should
 * reflect the installed path to the file, not its location in the source.
 */

#ifndef	_SYS_FOO_H
#define	_SYS_FOO_H

#pragma ident	"%Z%%M%	%I%	%E% SMI"

/*
 * Include any headers you depend on.
 */
#include <sys/bar.h>

#ifdef	__cplusplus
extern "C" {
#endif

/*
 * Main body of <sys/foo.h> header file goes here.
 */

#ifdef	__cplusplus
}
#endif

#endif	/* _SYS_FOO_H */


From msw@polyslo Tue Apr 27 17:34 PDT 1993
Date: Tue, 27 Apr 93 17:27:06 PDT
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: CodeMgr update #24: Removal of .del-* files from source base
Cc: on1093-gk@stufff
Content-Length: 2155
Content-Type: text
X-Lines: 58
Status: RO



THIS IS ONLY RELEVANT IF YOU WORK WITH THE OSNET SOURCE BASE - IF YOU DON'T
DELETE THIS MESSAGE NOW.

All,

I am about to do a big 'cleanup' of all of the .del-* files that we
have in the OSNet source base.  The .del-* files represent files that
have been deleted in our OsNet CodeMgr workspaces.  Because you can't
every 'truly' delete a file under CodeMgr we rename them to the .del-*
file name.  At last count we have 1900+ .del-* files in our source
base.  Its time we cleaned this up a little.  If you'd like to more
information on the .del-* files themselves please take a look at
the CodeMgr update #16 (/opt/teamware/doc/avo_updates) for more information.

I will be moving all of these .del-* files into a parallel source
tree where they should be 'more' out of the way.  Here is how
it will work.  For every .del-* files that is presently found under
usr/src/* in our source base I will move it into a parallel tree under
usr/deleted-files/*.  

	eg:
		...
		usr/src/lib/libnsl/.del-libnsl.mk-Dec-16-92
		usr/src/lib/libnsl/.del-Makefile.map-Jan-23-93
		usr/src/lib/libnsl/nis/cache/.del-sem.h-69035229
		...

	will all be moved to:

		...
		usr/deleted_files/lib/libnsl/.del-libnsl.mk-Dec-16-92
		usr/deleted_files/lib/libnsl/.del-Makefile.map-Jan-23-93
		usr/deleted_files/lib/libnsl/nis/cache/.del-sem.h-69035229
		...

Once this is done if you do a bringover of 'usr/src/uts' you will
bringover only the source code found under there and none of the over
600+ .del-* files that are presently under that tree.  This will make
your bringovers quicker and save on your disk space.

Once this big change is done I will continue to move new .del-* files
out of the usr/src/* source base over into the usr/deleted_files/*
tree.  These updates will happen periodically (probably weekly).


Executive Summary:

	o In the next couple of days or weeks you will see many renames
	  from usr/src/*/.del-* -> usr/deleted_files/*/.del-*.  Don't worry.
	o If you need to find a file that has been deleted it can now
	  be found under usr/src/deleted_files/*
	o These changes will be made to /ws/train (on1093) and propogate
	  down from there.
	

_Mike_

From msw@polyslo Wed Apr 28 12:49 PDT 1993
Date: Wed, 28 Apr 93 12:49:19 PDT
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: CodeMgr update #24.5 update: Removal of .del-* files from source base
Content-Length: 313
Content-Type: text
X-Lines: 11
Status: RO


UPDATE

After consulting with the CodeMgr development team we've decided to move
the deleted file structure to $CODEMGR_WS/deleted_files instead of
$CODEMGR_WS/usr/deleted_files.  This will match with future plans the
CodeMgr group has for introducing an sccsrm command similar to what we
already have.


_Mike_

From msw@polyslo Thu Aug 12 09:52 PDT 1993
Date: Thu, 12 Aug 1993 10:03:01 +0800
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: CodeMgr update #25 -- codereview utility
Cc: johnz@Eng
Content-Length: 2308
Content-Type: text
X-Lines: 79
Status: RO


All,

A new codereview utility has been added to the OsNet distribution
of TeamWare.  If you mount teamware off of dunk then no action
is required.  If you have a private copy of the OsNet teamware
you will have to copy the following file and symlink.


for 5.x codereview, see	dunk:/opt/teamware/bin/codereview  <symlink>
			dunk:/opt/teamware/OSNet/bin/codereview
			dunk:/opt/teamware/man/man1/codereview.1 <symlink>
			dunk:/opt/teamware/OsNet/man/man1/codereview.1


This utility was put together by John Zolnowsky, if you have any questions
e-mail johnz@eng with them.

Here is the man page for the new utility:

--------

CODEREVIEW(1-LOCAL)  Misc. Reference Manual Page  CODEREVIEW(1-LOCAL)



NAME
     lwlp - Diff list generator

SYNOPSIS
     codereview [-r] oldfile newfile

DESCRIPTION
     The codereview command expects two ASCII text files as input
     and  produces  Postscript describing the differences between
     the files.  The first file is assumed to be the  older  ver-
     sion,  and  the  second file is assumed to be the newer ver-
     sion.  The output lists all  lines  from  both  files,  with
     lines changed from the first to the second being highlighted
     in gray.  Lines deleted from the first file  are  listed  in
     italic,  while  lines added to the second file are listed in
     bold.

OPTIONS
     -r         Enable page reversal so that the pages appear  in
               the   correct  sequence  in  the  output  tray  of
               printers like the Apple LaserWriter.  The  default
               is  to not perform page reversal, which is correct
               for printers like the NEC Silentwriter LC-890.

FILES
     /tmp/lwlpXXXXXX          -  temporary  file  used  for  page
     reversal

LIMITATIONS
     The maximum input line  length  is  1024  characters.   This
     should  not present a problem since the corresponding output
     line length would be too long to be  printed.   The  program
     silently truncates input lines that are too long.

NOTES
     The command
          pageview -right -h 17 -w  11  -Ws  1100  850  -dpi  100
     out.ps

     is useful for displaying the results of codereview.

AUTHOR
     John Zolnowsky
     SunSoft, Inc.








Sun Microsystems      Last change: 93/08/09                     1

From tadd@jurassic Fri Sep 17 20:00 PDT 1993
Date: Fri, 17 Sep 1993 19:55:23 +0800
From: tadd@jurassic (Tadd Ottman)
To: osnet-sde@stufff, merge@mtns
Subject: codemgr update #27 - new construction set
Content-Length: 616
Content-Type: text
X-Lines: 22
Status: RO


	Now available from dunk.eng are updated SUNWonbld packages
for *both* sparc and i386.

	To install version 2.0 for sparc do:
  pkgadd -d /net/dunk.eng/sdet/pkgs/2.0 SUNWonbld

	To install version 2.0.1 for i386 do:
  pkgadd -d /net/dunk.eng/sdet/pkgs/i386/2.0 SUNWonbld

	[ see newer messages for current locations ]

	These contain a new link to the binary install utility in its own
directory.  This allows you to switch between slow and fast install
utilities without causing rebuilds because of name changes in .make.state
files.

	The sparc version contains 5.3 versions of rpcgen, tic, and zic.


					Tadd


From bonwick@cathy Thu Aug 12 01:11 PDT 1993
Date: Thu, 12 Aug 1993 01:09:45 +0800
From: bonwick@cathy (Jeff Bonwick)
To: on1093-mp@raid
Cc: on-eng@benet
Subject: P1: avoiding mismerges
Status: RO
Content-Length: 2475
X-Lines: 62

I want to alert everyone to a somewhat common mistake that's quite easy
to make, often hard to detect once it's happened, but trivial to prevent:
silent mismerges.

The scenario:
-------------

A "silent mismerge" typically occurs like this: you get a copy of foo.c,
and start working on it.  Some time later, you want to incorporate your
changes into some workspace.  So, in that workspace, you check out foo.c,
overwrite it with the copy you've been working on, and check it in.
More than likely, you have just performed a silent mismerge: without
realizing it, you have deleted one or more deltas to this file.
And neither bringover nor putback -n can possibly detect the problem.

The problem:
------------

So, what went wrong?  Refer to the diagram below:

    1.1 -------- 1.2 -------- 1.3 -------- 1.4
                   \                       /
                    \                     /
                     ---- your changes ---

Let's say you started out with version 1.2 of foo.c, and applied some
changes to it.  Meanwhile, the train has been chugging along, and someone
else has made changes to foo.c, and put them back (version 1.3).  So when
you check out foo.c in your new workspace, then overwrite it with your
copy and check it in, the new delta (1.4) contains 1.2 (the version you
started with) plus your changes -- the changes from delta 1.3 are gone.
There is no way teamware can tell that you didn't mean to do this, because
all it knows is that you checked out the most recent version (1.3), made
changes, and checked them in -- it can't tell that the changes are
*semantically* incorrect.

Once this happens, unless the missing changes cause the system not to
compile or boot, it is very unlikely that it will be detected in the near
future.  Eventually, someone will notice that a bug they thought they had
closed (1.3) has somehow reappeared.

Avoiding the problem:
---------------------

Before checking in any file, look at the sccs diffs.  If they contain
*anything at all* that doesn't look like your changes, don't check it in!
How you resolve the problem is up to you -- you can bring your copy up to
date, or you can just get a fresh copy of the file and re-apply your
changes there (this is usually the safest approach).

This is particularly important now that we're in FCS phase.  A silent
mismerge can turn any "trivial one-line fix" into a major disaster.

So please: diffs before delget!

Jeff


----- End Included Message -----




From tadd@jurassic  Wed Sep 22 20:12:45 1993
Date: Wed, 22 Sep 1993 19:43:50 +0800
From: tadd@jurassic (Tadd Ottman)
To: osnet-sde@stufff
Subject: codemgr update #28 - ws updated and mk_bld_space introduced
Content-Length: 955
X-Lines: 26
Status: RO

	Former Subject: ws script and mk_bld_space script updated


OS-Networking teamware users,

	On dunk.eng I have updated two scripts we always add to teamware
as customizations; these are ws and mk_bld_space.

	For ws, I cut old "avocet" support and added the setting of the
MACH shell variable for 5.x builds.  The value for MACH comes from
running uname -p.  Merged makefiles depend on this, per the CST
engineering guide.

	For mk_bld_space, I "taught" it to skip s-dot files found
in the backup subdirectory of Codemgr_wsdata directories.  In extreme
cases, this could save you MBs of disk space in a "bld_space", since
the backup files are for workspace undo operations having nothing to
do with test builds.

	Please use version 1.26 of ws and version 1.3 of mk_bld_space.

	If you NFS mount teamware from dunk, you will already see these
versions.  Otherwise, you will await an update of your locally exported
reference copy of teamware.

					Tadd

From msw@polyslo Fri Oct  8 17:40 PDT 1993
Date: Fri, 8 Oct 1993 17:38:42 +0800
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: codemgr update #29 - ws updated to support multiple architectures
Content-Length: 920
Content-Type: text
X-Lines: 23
Status: RO


OS-Networking teamware users,

	On dunk.eng I have updated ws, one of the OsNet additions to
teamware, to support both x86 & sparc proto areas.  ws now has an
'architecture' aware default location for the PROTO areas, the
ROOT, ENVCPPFLAGS{1-4}, and ENVLDLIBS{1-3} will be built in the following
way:
		ROOT=${CODEMGR_WS}/proto/root_{i386|sparc}

	PROTO's will now be set in the following way.  If, when ws is
activated, there is already an 'old' PROTO area present, then the 
env variables will be set as usual.  If, however, there is no 'old' PROTO
area present, it will set the env variables as ROOT is set above.

	This new setting is done to support the possibility of a 
single workspace containing, and exporting, multiple PROTO areas.  Soon
the Gatekeeper workspaces will be exporting this new format of PROTO areas
and you will be able to look to them for *both* sparc and i386 headers
and libraries.


_Mike_

From tadd@jurassic Wed Dec 15 11:15 PST 1993
Date: Wed, 15 Dec 1993 11:08:48 -0800
From: tadd@jurassic (Tadd Ottman)
To: osnet-sde@stufff
Subject: codemgr update #30 - teamware distribution changed
Content-Length: 1960
Content-Type: text
X-Lines: 43
Status: RO


OS-Net teamware users,

	Please modify your vfstab or automount maps to take advantage
of this new structure.

	The distribution of OS-Net development tools from dunk.eng has
been restructured.  Tools such as teamware, gatekeeper utilities, and
construction sets are primarily available through NFS and secondarily
through packages.  SPARC and X86 are handled side-by-side and nearly
identically.

	X86 users will no longer have to install teamware locally and
modify it with a script to install OS-Net customizations.  Instead,
x86 users may mount a customized teamware directory via NFS from dunk.

	Dunk will NFS-share reference tools in runnable format from
dunk.eng:/sdet/export/$MACH, where MACH is "sparc" or "i386" from uname -p.
For your convenience and my illustration, here are suggested vfstab lines:

On x86, you could put these lines in your vfstab:
 dunk.eng:/sdet/export/i386/opt/SUNWspro - /opt/SUNWspro nfs - yes ro,bg
 dunk.eng:/sdet/export/i386/opt/onbld    - /opt/onbld    nfs - yes ro,bg

On sparc, you could put these lines in your vfstab:
 dunk.eng:/sdet/export/sparc/opt/teamware - /opt/teamware nfs - yes ro,bg
 dunk.eng:/sdet/export/sparc/opt/onbld    - /opt/onbld    nfs - yes ro,bg

	Doing specific NFS mounts in this way keeps the tools in /opt but
permits you to install other items into /opt on your local disk.

	/opt/teamware for sparc continues to be Teamware only, without
compilers, while /opt/SUNWspro for x86 continues its traditional combination
of teamware and compilers.

	The old "dunk:/opt/teamware" mount will continue to export an
alternative path to the sparc teamware directory but not forever.

	Installing tools locally with pkgadd is optional and unnecessary.
If you wish to do so anyway, you will find packages for your architecture
in dunk.eng:/sdet/pkgs/$MACH.  The groupings below MACH are by function:
onbld, ongk, ld_patch, and make_patch.  (symlinks for the old name space
will go away someday soon.)

From tadd@jurassic Wed Dec 15 11:16 PST 1993
Date: Wed, 15 Dec 1993 11:10:28 -0800
From: tadd@jurassic (Tadd Ottman)
To: osnet-sde@stufff
Subject: codemgr update #31 - teamware customizations expanded
Content-Length: 2675
Content-Type: text
X-Lines: 82
Status: RO


OS-Net teamware users,

	Software development tools for OS-Net have been updated.

	Our customizations to teamware have been expanded and made more
consistent between x86 and sparc.  Both architectures contain an Rtitool
directory, the mk_bld_space script, the Install script, bfu (and the
fastfs it needs), the codereview utility, and a new script called newdeltas.

Here are brief descriptions of the Teamware customizations.  For more
information, you can find man pages for few of these items and you can
read the scripts for their internal documentation.  Previous announcements
of customizations are archived in the avo_updates mail folder in the
teamware/doc directory.

These are new on both sparc and x86:

newdeltas
	A script for listing source files modified in a workspace since a
	given date and the contents of the corresponding diffs.  This is
	convenient for generating the data a peer reviewer would study.

mk_bld_space
	a script providing an instruction-set-specific snapshot of source
	without SCCS history files, to do sparc and i386 builds with less
	wasted disk space.


These are new on x86:

rtitool
	A GUI for submitting Requests To Integrate implementations of
	bug fixes and requested enhancements.  This has a man page.

Install
	Jeff Bonwick's creative script for installing a kernel and kernel
	modules onto a target system directly from the binaries built in
	a workspace.  A "proto" area is not necessary, just "make all"
	in usr/src/uts.

bfu
	Bonwick, Faulkner Upgrade, utilizing fastfs to write a cpio archive
	image of the OS on top of a live target system.  The archives are
	the same as those created by "nightly" and submitted to PIT by
	gatekeepers.

codereview
	A utility for creating custom listings of source code for submitting
	to a PostScript printer, yielding a nice format for code reviews.


These are older customizations:

cstyle
	A perl script for checking many attributes of our C coding style.

hdrchk
	A perl script for checking header files for header guards and other
	required features.  [ See codemgr update #23 ]

perl
	Included to run perl scripts.

sccscp
	Script to facilitate copying SCCS files to fork work, with history.

sccsmv
	Script to facilitate moving SCCS files around and renaming them.

sccsrm
	Script to remove SCCS files in a Teamware-supported, official way.

ws
	Script to "activate" a workspace, giving a shell in which to do
	builds that reference libraries and header files in the workspace
	and in its parent workspace.

def.dir.flp
	Modified version of Teamware's file-list program, a script that
	finds and lists the names of files for Teamware operations such
	as bringover and putback.

From bonwick@cathy Mon Aug 15 06:51 PDT 1994
Date: Mon, 15 Aug 1994 06:45:06 -0700
From: bonwick@cathy (Jeff Bonwick)
To: on-eng@benet
Subject: P1: command-line resolve is unsafe
Content-Length: 4584
Content-Type: text
Status: RO
X-Lines: 201

There's a bug in diff3 that can cause it to silently mismerge files.
This is truly frightening because teamware's command-line resolve
depends on diff3 to perform the merge.  The reproducible test case
in the bug report below is derived from files on which I personally
experienced the problem.

The GUI version (filemerge) does not depend on diff3 and thus
doesn't exhibit the bug.  I strongly recommend that you avoid
using command-line merge until this problem is addressed.

Jeff

----- Begin Included Message -----

From bonwick Mon Aug 15 06:06 PDT 1994
Subject: 1174768: Bug report created.
To: bonwick@cathy, bugforward@elmer, tadd@eng, msw@polyslo, cmh@Eng,
        raf@sunraf


 Bug Id: 1174768
 Category: utility
 Subcategory: program
 Bug/Rfe: bug
 Synopsis: diff3 can silently mismerge files
 Keywords: 
 Severity: 1
 Priority: 1
 Responsible Engineer: 
 Description: 
bonwick, 94/08/15:

diff3 can silently mismerge files.  The following three files
demonstrate the problem:

::::::::::::::
child
::::::::::::::
	extern void	clkstart();
	extern void	post_startup();

	clkstart();

	post_startup();
	/* create kmem async thread */
::::::::::::::
ancestor
::::::::::::::
	extern void	clkstart();
	extern void	post_startup();

	clkstart();

	post_startup();
	/* create kma daemon */
::::::::::::::
parent
::::::::::::::
	extern void	post_startup();

	post_startup();
	/* create kma daemon */

The changes are trivial and do not overlap.
The child just changed a comment:

$ diff ancestor child
7c7
< 	/* create kma daemon */
---
> 	/* create kmem async thread */

and the parent just removed clkstart():

$ diff ancestor parent
1d0
< 	extern void	clkstart();
3,4d1
< 
< 	clkstart();

Using diff3 -E to merge the files as follows:

	cp child merge
	diff3 -E child ancestor parent | ed - merge

yelds the following merged result:

$ cat merge
	extern void	post_startup();

	clkstart();

	post_startup();
	/* create kmem async thread */

The declaration of clkstart() is gone, as it should be, but the
call to clkstart() is still there!

Interestingly, doing the merge in the other order (reversing the
sense of parent and child) works correctly:

	cp parent merge
	diff3 -E parent ancestor child | ed - merge

yields the expected result:

$ cat merge
	extern void	post_startup();

	post_startup();
	/* create kmem async thread */

**********************************************************************
This is truly frightening because teamware's command-line resolve
depends on diff3 to perform the merge.  The above files are condensed
versions of files on which I actually experienced a bad resolve.
**********************************************************************

I don't know what the problem is but I have a suspicion.
diff3 ultimately invokes /usr/lib/diff3prog with pre-computed
diffs of files 1 and 2 against file 3.  Check this out:

$ diff child parent
1d0
< 	extern void	clkstart();
4,5d2
< 	clkstart();
< 
7c4
< 	/* create kmem async thread */
---
> 	/* create kma daemon */

$ diff ancestor parent
1d0
< 	extern void	clkstart();
3,4d1
< 
< 	clkstart();

Notice that in the first diff, the call to clkstart() and the *following*
blank line are deleted.  In the second diff, the call to clkstart() and
the *preceding* blank line are deleted.  There's nothing wrong with
this -- the diff is ambiguous and either way is correct.  But I suspect
this may be confusing diff3.  If I save these diffs into files and
manually modify either one of the clkstart() diffs to match the other,
and then invoke /usr/lib/diff3prog -E with these diffs, the merge
comes out correct.

Apparently this bug is ancient.  I've verified that SunOS 5.x, SunOS 4.x,
generic SVR4, and 4.3BSD all have the same problem.

 Work around: 

 Suggested fix: 

 Justification: 
Justification by: bonwick                 Date: 8/15/94  Create with Priority 1:

This bug can silently corrupt our source base since teamware's
command-line resolve relies on diff3 to perform the merge.

 State triggers: 
	Accepted: no
	Evaluation: 

	Commit to fix in releases: 
	Fixed in releases: 
	Integrated in releases: 
	Verified in releases: 
 Comments: 

Introduced in release: 
 Root cause: 
 Development Status: 
 Fix affects documentation: 
 Interest list: tadd, msw, cmh, raf
 Patch id: 
 See also: 

 Called in by: 
    Customer:
	Company: Sun Microsystems
	Employee: Jeff Bonwick
	Release: s495_dev_phase
	Hardware version: generic
	O/S version: s495_dev_phase
	User Type: D
	SO Number: 
	Sun Contact: bonwick
 Public Summary: 

 Hook 1: 
 Hook 2: 
 Bug End:



----- End Included Message -----


From janet@firenze Thu Sep  1 18:32:38 1994
Date: Thu, 1 Sep 1994 18:29:49 +0800
From: janet@firenze (Janet Timbol)
To: osnet-sde@stufff
Subject: Updates on dunk: mk_bld_space, hdrchk, makestyle
Cc: suhas@jurassic, janet@firenze
Content-Length: 1401
Status: RO
X-Lines: 51


The following updates are now available on 'dunk':

  o mk_bld_space:
        1164129 : mk_bld_space should not follow symlinks to directories

  o hdrchk:
        1151627 : hdrchk forces use of /usr/dist/exe/perl
        1174068 : hdrchk should allow SunSoft S form of keywords
        1174071 : hdrchk should be able to accept continuation of 
                  ifdef statements

  o makestyle:
        <no bugid>: accepts "pragma ident" as a valid identifier

  o makestyle.1:
	Document the dependency on SRC environment variable

LOCATION OF FILES:
-----------------

If you mount teamware from dunk, no action is required.  However,
if you maintain a private copy of the OSNet teamware distribution, 
you will have to copy the following files:

   Shell Scripts:

	dunk:/opt/teamware/OSNet/bin/hdrchk
        dunk:/opt/teamware/OSNet/bin/mk_bld_space
        dunk:/opt/teamware/OSNet/bin/makestyle

   Manpage:
        dunk:/opt/teamware/OSNet/man/man1/makestyle.1

The arch-specific symlinks for people who mount teamware are:

sparc:
        dunk:/sdet/export/sparc/opt/teamware/bin/\
             {hdrchk,mk_bld_space,makestyle}
 
i386:
        dunk:/sdet/export/i386/opt/SUNWspro/OSNet/bin/\
             {hdrchk,mk_bld_space,makestyle}

BUGS/RFEs:
---------

Please send your feedback, comments and rfe's to suhas.patil@eng
and file your bugs in consolidation/os-net-tools category.

janet

From janet@firenze Thu Nov 10 15:50 PST 1994
Date: Thu, 10 Nov 1994 15:38:51 +0800
From: janet@firenze (Janet Timbol)
To: osnet-sde@stufff
Subject: Update: rtitool 2.4
Cc: gene.zombolas@Eng, janet@firenze, on494-mgrs@benet
Content-Length: 4008
Content-Type: text
X-Lines: 130
Status: RO


We have updated the rtitool and rtiroute binaries on dunk to 
reflect the bug fixes and enhancements listed at the bottom
of this mail message.

IMPORTANT NOTES: PLEASE READ THIS!!

  1)	The new version of rtiroute is _NOT_ backwards
	compatible for patch RTIs due to the addition of
	some fields.  Please restart 'rtitool' to avoid
	difficulties in submitting patch rtis.  (Backward
	compatibility is not an issue with implementor RTIs.)

  2)	We will occasionally be updating the rtiroute
	advocates.config file.  If you are mounting
	the teamware binaries from dunk, these changes
	will be transparent to you.  However, if you access 
	your own private copy of rtitool, please send me 
	mail to get on the notification alias for updates
	to the configuration file.

janet


-----------------
Rtitool bugs/rfes:
-----------------
 
Please send comments, bugs, rfe's for rtitool using:

   The Help/Send feedback... menu button.  This puts you in
   a mailtool compose window which will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.
 
-----------------
Rtitool location:
-----------------
 
Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, you will need to create or
update the files and symlinks from these directories:
 
for sparc rtitool, see:
 
        dunk:/sdet/export/sparc/opt/teamware/Rtitool
 
for x86   rtitool, see:
 
        dunk:/sdet/export/i386/opt/SUNWspro/Rtitool
 
================================================================
Important Note:
     Please reinvoke 'rtitool' to access these changes.
     The previous version will be *removed* within the next
     hour to enforce the upgrade.
================================================================


*************************************************************************
Rtitool 2.4:  RELEASE NOTES  
(by Gene Zombolas, Nov. 10, 1994)
*************************************************************************

============
rtitool rfes
============

o  Query of RTI extended to match implementor, patch, and archived patch
   RTIs with the same RTI number a single query.

o  Additional bugtraq checks added.  Rtitool now requires Responsible
   Manager, Responsible Engineer, and Suggested Fix to be defined in bugtraq
   for all bugids before a RTI can be submitted.

o  "Code Reviewed By" field added to the implementor RTI.

o  "Test Results" field added to patch RTI.

o  "Patch Request Origin" field added to patch RTI

o  New default choices for "Patch Justification".

o  Bugtraq checks (state, RM, RE, and Suggested Fix) are redone when an
   evaluator attempts to accept a RTI.

o  Changed approval implementor RTIs for a phase to a release.

o  Removed approval of patch RTIs for patch/point patch.

o  Cancel action added to evaluator's window.

=================
rtitool bug fixes
=================

o  Now works with different font families/sizes.

o  Ensure that the bugid(s) are followed by a blank line (required by
   rtiroute).

=============
rtiroute rfes
=============

o  Code reviewer CC'd on receipt of a new RTI

o  CC of patch gatekeeper on updates to patch RTIs.

o  Archive and open new RTI for canceled patch RTIs when create message
   received with a bugid of an existing patch RTI.

o  Mail messages sent by rtiroute now have "Precedence: bulk" to prevent
   the vacation program from responding to them.

o  Patch RTI fields deliverable sources and deliverable objects now
   replace the previous value on a update or appeal.

o  Daily summaries now include all RTIs which are not in the accept or cancel
   states in addition to all RTIs which were acted upon in the last 24 hours.

==================
rtiroute bug fixes
==================

o  Evaluator comments now correctly included (under the heading Evaluator
   Comments:) in the extracted RTI sent to prtiroute.

o  Fixed bug where rtiroute munged lines with a % in included or forwarded
   mail messages.

From janet@firenze Mon Apr 10 13:18 PDT 1995
Date: Mon, 10 Apr 1995 13:13:40 -0700
From: janet@firenze (Janet Timbol)
To: osnet-sde@stufff
Subject: codereview updates
Cc: janet@firenze, johnz@firenze
Content-Type: text
Content-Length: 763
X-Lines: 21
Status: RO


The 'codereview' utility has been updated by John Zolnowsky
to support a -h<string> argument to specify a header string to 
appear on each page of the listing.  The header appears on the 
upper left, and the page number is displayed on the upper right.
 
If you mount teamware from dunk, you need not do anything to access
the updated utility and manpage.  However, if you maintain your 
own private distribution, please copy the following:
 
 BINARY: 
  sparc:  dunk:/sdet/export/sparc/opt/teamware/bin/codereview
  i386:   dunk:/sdet/export/i386/opt/SUNWspro/OSNet/bin/codereview
 
  sparc/i386:  dunk:/opt/teamware/OSNet/bin/cstyle 
               (minor bug fix in January)   
 
 MANPAGE::
  dunk:/sdet/export/sparc/opt/teamware/man/man1/codereview.1

janet

From janet@firenze Mon May  1 12:36 PDT 1995
Date: Mon, 1 May 1995 12:34:42 -0700
From: janet@firenze (Janet Timbol)
To: osnet-sde@stufff
Subject: Updated cstyle
Cc: ns@morale, shannon@datsun, all-int@plunge, frits@jurassic, jek3@jurassic
Content-Type: text
Content-Length: 564
Status: RO
X-Lines: 17


A new version of 'cstyle' has been pushed to dunk.  This
version recognizes and ignores the contents of the new
style of source code annotation which has recently been
given ARC-approval.  For example:

   _NOTE(MUTEX_PROTECTS_DATA(mutex1, some_struct_tag::{a b c d e}))

(See /shared/sac/LSARC/1993/510/opinion.txt for details). 

If you mount teamware from dunk, you need not do anything to access
the updated cstyle.  However, if you maintain your own private
distribution, please copy this shell script from:

      dunk:/opt/teamware/OSNet/bin/cstyle

janet

