Overview of the revision librarian for Windows 95
-------------------------------------------------

The point of this package is to allow simple revision control using the
icon interface of windows 95 and the RCS utilities which are available
for Winnt (which also work on windows 95).

It's a fairly initial version, which is really designed for one user
keeping files locally, though I think that if the files are stored
on a central server and accessed from that directory then the interface
would also work satisfactorily.  The technique needs some finishing
touches, but is workable as it is.

These utilities may work on Windows NT.  This isn't tested but there's
no obvious reason why they shouldn't work.

The utility functions were compiled using BCC 4.5 from the IDE .  I
generated a .MAK file, but I haven't tested it.  The utilities are
compiled as win32 console programs.  They can be compiled seperately,
which is how they were developed and tested, but in this package I
build them as functions within the revlib&u program so there are fewer
files in the package.


The life cycle of a document is as follows.
------------------------------------------
1 - the user creates a document in a directory where such documents are
    stored.

2 - when a version of the document is completed then the user drags
    it onto the "do revision librarian .bat" icon, or right clicks and
    uses "Send To >" to send the document to the "revision librarian".

3 - the original icon is replaced with a new icon "original-name .Title"
    and the original document is rcs'ed out of sight, into a (possibly
    new) subdirectory called RCS.

4 - later, the user can click on the .Title icon to access the original
    document, either as a master copy (which can be checked in later
    after further changes are made) or a regular copy which can not be
    checked in later.  These copies are left in the original working
    directory.



How it works
------------

When I refer to a library, I am refering to the RCS control files stored
in an RCS directory.

This package is just a batch file wrapper to the RCS utilities.  The batch
file is started when a file with a registered extension is double clicked,
or when the batch file is double clicked itself.  The batch file will not
normally close after running, which is annoying, and hence the need for
the .PIF files.

   Batch and pif file notes: If a .BAT file is in the path then the
   associated .PIF file can start the batch file without specifying the
   batch files full path.  If a .BAT file is started directly, and if
   the associated .PIF file is in the path, then the settings of the
   .PIF file will be used.

When you drag and drop a file onto a batch file or a .PIF file, then the
batch file is started with the %1 parameter set to the full name of the
drag and dropped file.  Likewise when "Send To >" is used.

One issue is that when a file is dropped onto a .PIF file, then the batch
file that runs has no way of finding out what directory the .PIF file was
in.  Hence, to allow a user to drag and drop a master copy from one folder
into the library of another folder, the drop destination must be a batch
file.  (The batch file can find its own directory from the %0 parametre.)

The batch file identifies the extension of the file name it receives,
and then displays different menus of options based on what type of file
it is.  Unrecognized file types are assumed to be original documents.

When an option is selected, then the appropriate RCS function is called,
along with a few wrapping statements to make it all work.

To open a document, the original document type (embedded in the filename)
is used to lookup the associated command from the registry.  One issue is
that some applications are started using DDE.  The librarian doesn't use
DDE, it simply invokes the command from a temporary batch file.  The
associated application command may not include the %1 parameter, so this
is added if its not in the command line.  Some applications may not work
with this technique.  Also, this can start multiple copies of an
application.

Not all the functions can be easily done using DOS, and so a few extra
utilities had to be written.  They pass data to the batch file by
creating temporary batch files which use the DOS SET command to set the
value into the DOS environment.  The main batch files first runs the
utility, and then CALLs the temporary batch file.  The utilities are
all included in a single front end to reduce the number of files in the
package, and so the names of the utilities are not likely to collide
with other utilities.  None of utilities is really general purpose enough
to warrant being its own program.


Compiling the C programs
------------------------

In this version there are some warning messages that you must simply ignore.
