To:	SMGR Users

From:	Neal Rhodes /MNOP Ltd

Subject: FEEDING BACK REVISION DATA FROM DEPLOYED SITES		[#3]

We are working on automatic processes to feedback information regarding 
deployed revisions.   This has uncovered some dependencies on how your 
revision strings are set up, so I wanted to give some advance notice. 

We want to implement a fail-safe mechanism, which can be invoked after any 
files have been deployed.   This mechanism can grab all the revision data for
all .r files and send it back to the SMGR host system for incorporation.  Thus
we should always have accurate revision data, even if the deployment job fails,
OR the remote site cleverly wipes out our changes later on.   The revision
feedback job would look something like this:
	cd /usr/prod/whatever		# Change for your system
	rm -f /tmp/revdata
	for DIR in ar ap gl so in pr fa # Change for your runtime dirs
	do
		mwhat -all $DIR/* >> /tmp/revdata
	done
	compress < /tmp/revdata | uux - homesystem!rcvrevs mysite
	
A potential logical problem is figuring out categories.   SMGR uses both 
filename and category name to uniquely identify a source.   There can be
several situations which prevail at your site:

1. All names are unique within the application, and there is no ambiguity.  
QAD software is an example of this situation.

2. Like #1, but there may be some custom programs for this location.  
Therefore, given a filename it would be in the base category UNLESS the same
name exists in a special category for this deployed location.   (This is 
getting squishy and arm-wavy and smelly)

3. The same name is used in multiple places in the deployed system.  
Varnet/Marcam software is an example of this.  The filename "customer" exists
in several subdirectories.  In one instance it is a file maintenance program, 
in another it is an inquiry program.   So one could hope to keep this straight
by directory and category.   But the potential for the right file in the wrong
place is great. 

4. Like #3, but there may be some custom programs for this location.   This is
an absolute mess to make sense out of. 

We feel the best way to address this is to always retain the category identity
within the revision string.   That will handle all of the above situations. 
This would entail placing the category name between the %I% (rev) and %D%
(date) fields like this: 
	def var sccsid as char init "%Z% %M% %I% gl %D% %Q%" no-undo.
	OR
	form "%Z% %M% %I% gl %D% %Q%" with frame sccsid.

We have modified the mwhat revision display program to rev 1.4 to include the 
category field in its output. 

So, we are suggesting that you might want to make this change to your sources 
if you intend to use the deployment tracking capabilities.   Of course, you may
now be saying, "Great Neal, but I've already added 4,000 sources!  You don't 
expect me to checkout each and every one of them and alter the rev string!"

No, I don't.   We have added a script called "zaphdr" as follows:

-----------------------------------------------------------------------
#"@(#) zaphdr 1.1 smgr 94/11/27 " 
#Copyright 1994 Pat Rhodes, Neal Rhodes, MNOP Ltd. All rights reserved. 

set -x				# Delete this if you don't like to watch
DIR=`pwd`
CAT=`basename $DIR`
for FILE in s.*
do
	mv $FILE $FILE.old
	sed -e "s/\%I\% \%D\%/\%I\% $CAT \%D\%/" $FILE.old > $FILE
	chmod a-w $FILE
	admin -z $FILE
	read JUNK		# Delete this if you don't want it to stop
done
--------------------------------------------------------------------------
You can place it in your $SMGRHOME/bin directory, then climb into each category
subdirectory within $SMGRHOME/data and run it.   Each time it is run it will 
alter all the Sccs master files in that category, leaving a copy of the prior
file with a .old suffix.  You can elect to move, delete, whatever the .old 
file.   Note that this will not result in a new revision per se.  In fact, it
is really "cheating" by altering the Sccs master file, then recalculating the 
internal checksum. 

After doing this you should find that the revision marker strings of any files
Fetched should contain the category, like this: 
	glinq.p: glinq.p 5.1 gl 94/11/27 

Deploying these sources will make it easier to handle revision feedback if 
your source file names suffer from any of the ambiguities we named above.