This details exactly what to do when editing mudlib files.
Mudlib files should never be edited *in any form* on Nightmare.  This
means files in the following directories:
/cmds
/verbs
/secure/cmds
/secure/daemon
/lib

All editing is done on Dead Souls.  A file only EVER gets to Nightmare
by performing a 'migrate' operation, which I will describe later.  For
the sake of this document, the "development system" is /mud/DeadSouls/
and the "production system" is /mud/Nightmare.  The "development
environment" is the mud Dead Souls and the "production environment" is
the mud Nightmare.

The utilities you will use, checkin, checkout, and migrate require
certain environment variables to be set.  Add these lines to your
.login or .profile on athens:

setenv DEV /mud/DeadSouls/lib
setenv PRD /mud/Nightmare/lib

      **********************************************************
			   MODIFYING A FILE

Editing involves the following steps:
#1 Checking out the target file in the development system.
#2 Editing that file using vi, emacs, or whatever OR editing that file
   on your local system and copying it over when ready.
#3 Testing your version in the development environment.
#4 Checking in your changes.
#5 Migrating your changes to the production environment.

				*****
#1 Checking out a file
To do this, simply use the command:
checkout FILENAME

This will give you an editable copy of the file and lock it for ONLY
you to be able to use.  If someone else already holds a lock on that
file, you will get an error and will not be allowed to edit it.

				*****
#2 Editing a file
This is where you make changes to the file.  Go nuts.  The advantage
to this system is that if you really screw up, you can always backout
changes.  More important, everyone else can see exactly what changes
you made.  VERY IMPORTANT:  Always check out a file before making any
modifications.  A recipe for disaster is the following situation:  You
copy the file to your home machine to edit.  In the mean time, I check
it out, make edits, and check it back in.  You finish your edits,
login to athens, checkout the file, copy your local version over, and
check it in.  All my changes are lost!  Before ever even copying the
file to your system, you should thus check it out so no one else can
make edits to it.

				*****
#3 Testing your changes
Before checking in the file, make sure it works. Update it in the
development environment, use it in game situations and make sure it
does what it is supposed to.

				*****
#4 Checking in the file
Use the command:
checkin FILENAME

This will release your lock on the file, update the file version, and
get a copy of the file with all the version and last modified
information filled int.

				*****
#5 Migrating a file
Migating a file means moving it from development to production.  To do
this, simply use the command:
migrate FILENAME

You should be in the same directory as the file on the development
system when you do this.  This utility knows where the production
system is based on your environment variable settings.

      **********************************************************
			   CREATING A FILE

The following steps are involved in creating a file:
#1 Create the file
#2 Create it in SCCS
#3 Migrate it

#1 Create the file
Do whatever you normally do in creating a file.  The only special
thing you need to remember is what to include in the header.  All
headers should look like this:
/*    FILENAME
 *    From Nightmare LPMud OR From the Nightmare V Object Library
 *    Created by YOURNAME EURODATE
 *    Version: %A%
 *    Last modified: %D%
 */
Whether you say from NM LPMud or the object library depends on whether
the file is for general distribution.

The %A% and %D% things are called tokens.  When you check out and
migrate a file, SCCS automatically expands those values.  They are very
important to have when trying to understand where something went wrong.

				*****
#2 Creating the file in SCCS
Issue the commands:
sccs create FILENAME
This will be much like checking the file name in, except it does extra
stuff.  After creating the file, you should not edit it again unless
you check it out accoding to the steps listed above in the modifying
section.

One side effect of this step is the creation of a file called
,FILENAME (note the comma).  Just rm it.  It is supposed to be a
backup file in case the sccs create went horribly wrong.

#3 Migrating the new file
Use the migrate command as listed above.

      **********************************************************
			  POTENTIAL PROBLEMS

SCCS is really touchy about file permissions.  If you try to checkout
a file that is writeable, it throws a fit.  There should be NO
writeable files on the system except those checked out.  Some files
are still writeable though from before we went on this system.  Let me
know if you encounter this problem.  And by all means NEVER EVER chmod
any files in the development or production systems.

      **********************************************************
			  USEFUL INFORMATION

What changed?
man sccs and look at the diffs section.  This will be our last
salvation in the event that one of us sticks in code that makes the
mud go haywire and another one of us is left to figure out what the
hell happened.  The commands 'sccs diffs FILENAME' will show you what
has changed on the file you are editing between now and the last
version.  You can, however, do much, much more than that.

Backing out changes
SCCS lets you go back to any version of a file you like.  Take a look
at the get section of the SCCS man page.