Zymbolic history management system

Abstract

A zymbolic history management system (ZHMS) allows a user to create annotated symbolic links (zymlinks) to files in a shared file system. A single link is created to each file of the shared file system which a user wishes to access. A zymlink to the shared file system may be updated via a zupdate command. Rather than selectively updateing individual files, a user simply zupdate's whole trees of files. When it comes time to edit files, a user makes use of standard history managed file system commands to obtain a writable copy of a file. Use of one of these commands destroys a zymlink corresponding to the file, and substitutes a privately owned copy of the file on a user's disk. When the edited file is checked back into the history managed file system, a read-only copy of the file remains on a user's disk. When a user updates his or her file system, the read-only file copy may be replaced with a new zymlink. A user will normally view current versions of shared files. Rather than viewing current versions of shared files, a user may wish to maintain a static view of file versions by issuing a zreset command. The system provides a user with more free disk space than in conventional history managed systems.

Claims

What is claimed is:

1. A computer implemented method for allowing a user to access a plurality of files stored in one or more computer accessible storage medias, and more specifically, a method for allowing a user to access specific versions of the plurality of files, the method comprising:

a) constructing a plurality of file versions to be stored within a shared file system, said file versions being constructed from a plurality of file revision archives stored in a history managed file system, said shared and history managed file systems being logically separate from one another;

b) providing a plurality of user file systems with read-only access to the shared file system, said plurality of user file systems being logically separate from both the shared file system, the history managed file system, and each other, and said plurality of user file systems already having read/write access to the history managed file system;

c) mapping directory hierarchies of the plurality of user file systems into directory hierarchies of the shared file system;

d) creating a plurality of files under the directory hierarchies of a user file system wherein each of the created files is a symbolic link corresponding to a file version comprising the shared file system, said correspondence of symbolic links and file versions being based on the mappings of directory hierarchies;

e) creating first revision information files, said first revision information files being derived from said file revision archives, each first revision information file comprising file revision information corresponding to the file versions of one or more directories of the shared file system's directory hierarchies; and

f) creating second revision information files, said second revision information files being initially derived from said first revision information files, each second revision information file comprising file revision information corresponding to the symbolic links of one or more of a user file system's directory hierarchies.

2. A method as in claim 1, further comprising the steps of:

a) destroying a symbolic link when one of the plurality of user file systems requires a writable copy of a file; and

b) replacing said destroyed symbolic link with a proprietary copy of a file obtained from one of the plurality of file revision archives, said writable copy of the file possibly comprising a file version which differs from the file version with which the destroyed symbolic link corresponded.

3. A method as in claim 2, further comprising the step of updating the plurality of file versions and first revision information files of the shared file system.

4. A method as in claim 3, wherein the step of updating the shared file system comprises issuing a zrevfupdate command.

5. A method as in claim 3, further comprising the step of updating the symbolic links of a user file system.

6. A method as in claim 5, wherein the step of updating the symbolic links in a user file system comprises:

a) replacing, if possible, a proprietary copy of a file in the user file system with a new symbolic link to a version of the proprietary file comprising the second file system; and

b) updating file revision information in second revision information files corresponding to the updated symbolic links.

7. A method as in claim 6, wherein the step of updating the symbolic links of a user file system comprises issuing a zupdate command.

8. A method as in claim 3, further comprising the step of resetting the symbolic links of a user file system in order to circumvent an update to the shared file system.

9. A method as in claim 8, wherein the step of resetting the symbolic links of a user file system comprises:

a) acknowledging, from the standpoint of a user file system, that the shared file system has been updated; and

b) obtaining for the user file system, a read-only proprietary version of a file version which no longer exists as part of the shared file system.

10. A method as in claim 9, wherein the step of resetting the symbolic links of a user file system comprises issuing a zreset command.

11. A system stored in one or more computer readable storage medias for allowing a user to access a plurality of files, and more particularly, specific versions of the plurality of files, the system comprising:

a) a shared file system, and a plurality of user file systems, all of said file systems being physically stored within the one or more computer readable storage medias as logically separate file systems,

i) said shared file system employing read-only access to a number of file revision archives stored in a history managed file system which is logically separate from said shared and plurality of user file systems, said shared file system comprising,

A) a plurality of file versions, organized in directory hierarchies and derived from said file revision archives; and

B) first revision information files, also derived from said file revision archives, each first revision information file comprising file revision information corresponding to the file versions of one or more directories of the shared file system's directory hierarchies;

ii) said plurality of user file systems having read-only access to said plurality of file versions, and read/write access to said file revision archives;

b) a number of map entries, the number of map entries indicating which directory hierarchies comprising any of said plurality of user file systems correspond with the directory hierarchies of the shared file system;

c) a plurality of symbolic links stored as files in the directory hierarchies comprising any of the plurality of user file systems, each of said symbolic links corresponding to a file version comprising the shared file system, said correspondence of symbolic links and file versions being based on the number of map entries; and

d) second revision information files, initially derived from said first revision information files, each second revision information file comprising file revision information corresponding to the symbolic links of one or more of a user file system's directory hierarchies.

12. A system as in claim 11, further comprising:

a) means for each of the plurality of user file systems to simultaneous read, via its symbolic links, the file versions comprising said second file system; and

b) means for each of the plurality of user file systems to obtain its own proprietary version of a file from said file revision archives.

13. A system as in claim 12, wherein the means for each of the plurality of user file systems to obtain its own proprietary version of a file from said file revision archives comprises means to destroy a symbolic link and replace it with a proprietary file version which may or may not be identical to the file version which was previously accessible via the symbolic link.

14. A system as in claim 13, further comprising:

a) means to update the plurality of file versions and first revision information files of the shared file system, said means being responsive to updates checked into the file revision archives;

b) means to update the symbolic links between a user file system and the shared file system, said means being independent of said means for updating the shared file system; and

c) means to reset the symbolic links of a user file system in order to circumvent an update to the shared file system.

15. A system as in claim 14, wherein said means for updating the shared file system comprises a zrevfupdate command.

16. A system as in claim 14, wherein said means for updating symbolic links comprises:

a) means to replace, if possible, a proprietary version of a file with a new symbolic link to a version of the proprietary file comprising the second file system; and

b) means to update file revision information in a second revision information file corresponding to an updated symbolic link.

17. A system as in claim 16, wherein said means for updating symbolic links comprises a zupdate command.

18. A system as in claim 14, wherein said means for resetting symbolic links comprises:

a) means for a user file system to acknowledge an update to the shared file system; and

b) means for a user file system to obtain a read-only proprietary version of a file version which no longer exists as part of the shared file system.

19. A system as in claim 18, wherein said means for resetting symbolic links comprises a zreset command.

20. A system as in claim 11, wherein:

a) said file systems exist as a network of servers and clients;

b) said shared and plurality of user file systems exist as clients of a first server servicing the file revision archives of a history managed file system;

c) said shared file system exists as a second server; and

d) said plurality of user file systems exist as clients of said second server.

Description

BACKGROUND OF THE INVENTION

This invention pertains to the viewing and accessing of history managed computer files, and more particularly, to a method and apparatus for allowing a user to 1) view logically private, but physically shared, history managed files, 2) obtain a user-owned physical copy of a history managed file when that file no longer exists within the realm of physically shared history managed files, and 3) simply manage his or her views of history managed files. The method and apparatus which is used to accomplish the above tasks is herein referred to as a Zymbolic History Management System (ZHMS).

ZHMS is an improvement to history managed file systems. In general, a history managed file system is a system used to maintain a set of archives representing the complete history of a set of design files. Revisions to a file are saved as "deltas" in a single file revision archive. Tools used to access the file revision archives insure the mutually exclusive creation of file versions (i.e., revisions). A log of revision information is stored in each file revision archive. The log may comprise author, revision number, date and time of modification, and commentary information.

A first generally accepted method of storing and managing file revisions was the Source Code Control System (SCCS). SCCS was developed as an aid in managing source code revisions and is described in detail in "The Source Code Control System" by Rochkind, IEEE Transactions on Software Engineering, Vol. SE-1, No. 4, pp. 364-370 (Dec. 1975), which is hereby incorporated by reference for all that it discloses.

An improvement over SCCS was the Revision Control System (RCS). RCS is described in detail in "Design, Implementation, and Evaluation of a Revision Control System" by Tichy, Proceedings of the IEEE 6th International Conference on Software Engineering, pp. 58-67, (Sep. 1982), which is hereby incorporated by reference for all that it discloses. The primary difference between RCS and SCCS is in the way deltas are stored and managed.

As design projects grew larger, and design engineers from across the country began to work on joint development projects, a method was needed for allowing programmers common access to a body of file revision archives, while at the same time providing each designer with private workspace in which he or she could work on new developments to a design project. A history managed file system which filled this need was HMS.

HMS is a client/server based system used to manage versioned files. A server is installed on a central computer and manages an HMS database of file revision archives. Numerous other computers, possibly of varying types (HMS supports multiple platforms) exist as clients of the server. HMS provides a hierarchical view of the files it manages. A commercial version of HMS has recently been released by Hewlett-Packard Company as "SoftBench CM". In summary, a history managed file system such as HMS comprises the following features:

1) transparent access to files distributed across a computer network,

2) maintenance of historical changes to a file, thereby allowing previous versions of a file to be accessed,

3) file check-in and check-out procedures (and means for a user to "lock" a file while making changes),

4) file references which are independent of storage location, and

5) the ability to access SCCS, RCS, binary and other versioned file types.

One of HMS's most important features is that a user's workspace is separate and hidden from the space which is used to maintain and manage file revision archives. A user's workspace is also separate from the workspace of any other user. Unfortunately, this feature is also one of the drawbacks of HMS. Since HMS requires a user to obtain a copy of each HMS file version he or she wishes to use, the amount of file storage space available to hold these "working" files can often be exceeded. As a result, a user may spend a significant amount of time managing their file storage space (i.e., deleting files to make room for additional files, and then re-retrieving the deleted files when they are once again needed). Hands-on management of file storage space reduces productivity, and fails to produce tangible progress. This is unfortunate, since a user typically modifies only a small fraction of the total number of files in his or her workspace, but requires read-only access to a much larger number of files.

It is therefore a primary object of this invention to provide a system of file history management wherein a user's file storage space remains logically private, but has access to a number of physically shared files.

It is a further object of this invention to provide a system of file history management wherein the shared files may be periodically updated.

It is yet another object of this invention to provide a system of file history management wherein a designer may undo a periodic update to the shared file system with respect to his or her logically separate view of the shared files.

It is an additional object of this invention to provide a system of file history management wherein a designer has the freedom to choose whether he or she reads shared files, or personally owned "physical" files.

SUMMARY OF THE INVENTION

In the achievement of the foregoing objects, the inventor has devised an improvement to a history managed file system. The improvement is stored in one or more computer accessible storage medias. The improvement (hereafter merely referred to as a "system" or "ZHMS") allows a user to access a plurality of files, and more particularly, specific versions of the plurality of files. ZHMS comprises a shared file system, and a plurality of user file systems, all of said file systems being physically stored within the one or more computer readable storage medias as logically separate file systems.

The shared file system employs read-only access to a number of file revision archives stored in a history managed file system which is logically separate from the shared and plurality of user file systems. The shared file system comprises a plurality of file versions, organized in directory hierarchies and derived from the file revision archives. It also comprises first revision information files derived from the file revision archives. Each first revision information file comprises file revision information corresponding to the file versions of one or more of the shared file system's directory hierarchies.

The plurality of user file systems have read-only access to the shared plurality of file versions, and read/write access to the file revision archives.

Map entries indicate which directory hierarchies comprising any of the plurality of user file systems correspond with the directory hierarchies of the shared file system.

A plurality of symbolic links are stored as files in the directory hierarchies comprising any of the plurality of user file systems. Each of the symbolic links corresponds to a file version comprising the shared file system. The correspondence of symbolic links and shared file versions is based on the map entries.

Finally, the system comprises second revision information files which are initially derived from the first revision information files. Each second revision information file comprises file revision information corresponding to the symbolic links of one or more of a user file system's directory hierarchies.

ZHMS offers important advantages over systems merely using HMS or other history managed file systems. Foremost, with ZHMS each user is not required to maintain separate copies of file versions in his or her own file system. The user merely stores links to a number of shared files. This allows a user to "free up" vast amounts of file storage space.

A user's links to the shared files are annotated symbolic links (referred to herein as "zymlinks"). The annotations are stored as part of a user's file system (second revision information files), but to a degree, reflect file revision information which is stored in the shared file system (first revision information files). Although comprising similar information, the revision information files are separately managed and maintained. The revision information files help assist a user in retaining a static view of files. For example, if the file versions of the shared file system are updated, a user may issue a command which uses the revision information files to retrieve older file versions directly from the history managed file system.

ZHMS alleviates a user's micro-management of files and directories by allowing him or her read-only access to whole trees of files (many more files than a user could access under HMS) without significantly impacting utilization of file storage space (i.e., disk space), or without requiring the physical sharing of a user's own directories.

These and other important advantages and objectives of the present invention will be further explained in, or will become apparent from, the accompanying description, drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

An illustrative and presently preferred embodiment of the invention is illustrated in the drawing in which:

FIG. 1 is a schematic illustrating the components of a ZHMS system, and the flow of data between these components;

FIG. 2 is a flow chart outlining the basic tasks performed by ZHMS;

FIG. 3 is a schematic illustrating a newly constructed shared file system;

FIG. 4 is a schematic illustrating newly created zymlinks in a user file system;

FIG. 5 is a schematic illustrating an update to the shared file system;

FIG. 6 is a schematic illustrating an update to a user file system; and

FIG. 7 is a schematic illustrating a reset of a user file system.

DESCRIPTION OF THE PREFERRED EMBODIMENT

1. Overview of ZHMS

The basic tasks 200 which might be performed by software implementing ZHMS (a zymbolic history management system) are outlined in the flow chart of FIG. 2. Note that all of the tasks 200 must be performed, but that their completion order is not critical. To begin, a shared file system 104 (FIG. 1) comprising a plurality of file versions 302-310 is constructed 202. The file versions 302-310 are constructed 202 from a plurality of file revision archives 312-324 stored in a history managed file system 102. The shared 104 and history managed 102 file systems are logically separated from one another. After the shared file system 104 is constructed 202, a plurality of user file systems 106-114 are provided 204 with read-only access to the shared file system 104. Each of the plurality of user file systems 106-114 is logically separated from the shared file system 104, the history managed file system 102, and each other. The plurality of user file systems 106-114 are understood to have read/write access to the history managed file system 102. Following the above tasks 202, 204, directory hierarchies 344 of the plurality of user file systems 106 are mapped 206 into directory hierarchies 326 of the shared file system 104. ›Note: As used in this description, the term "directory hierarchy" is used to refer to a directory, and when they exist, all subdirectories of the directory.! Using these mappings 352, a plurality of files 436-442 is created 208 under the directories of the directory hierarchies 344, 446, 448 (FIGS. 3, 4) of a user file system 106, wherein each of the created files 436-442 is a symbolic link corresponding to a file version 302-308 in the shared file system 104. First revision information files 354, 356 are created 210. The first revision information files 354, 356 are derived from the file revision archives 312-324 of the history managed file system 102. Each first revision information file 354, 356 comprises file revision information corresponding to the file versions 302-308 of one or more of the shared file system's directories 326, 328, 330. Second revision information files 450 (FIG. 4) are also created 212. The second revision information files 450 are initially derived from the first revision information files 354 and comprise file revision information corresponding to the symbolic links 436-442 of one or more of a user file system's directory hierarchies 344, 446, 448. After their initial derivation, the second revision information files 450 are managed and maintained separately from the first revision information files 354, 356.

Apparatus 100 used in implementing ZHMS is pictured in FIG. 1, The apparatus 100 may generally comprise a shared file system 104, and a plurality of user file systems 106-114. All of the file systems 104, 106-114 are physically stored within one or more computer accessible storage medias. However, each of the file systems 104 is logically separate from the other file systems 106-114. The shared file system 104 employs read-only access to a number of file revision archives 312-324 (FIG. 3) stored in a history managed file system 102. The history managed file system 102 is logically separate from both the shared 104 and plurality of user file systems 106-114. The shared file system 104 comprises a plurality of file versions 302-310, the file versions 302-310 being organized in hierarchical directories 326-334. The file versions 302-310 are derived from the file revision archives 312-320. The shared file system 104 also comprises first revision information files 354, 356, each first revision information file 354, 356 also being derived from the file revision archives 312-320. Each of the first revision information files 354 comprises file revision information corresponding to the file versions 302-308 of one or more of the shared file system's directories 326, 328, 330. The plurality of user file systems 106-114 have read-only access to the plurality of file versions 302-310 stored in the shared file system 104. The user file systems 106-114 also have read/write access to the file revision archives 312-324. A map entry 352 is required for indicating a correspondence between the directory hierarchies 344, 446, 448 (FIGS. 3, 4) comprising any of the plurality of user file systems 106 and the directory hierarchies 326, 328, 330 of the shared file system 104. A plurality of symbolic links are stored as files 436-442 in the directories of the directory hierarchies 344, 446, 448 comprising any of the plurality of user file systems 106. Each of the symbolic links 436-442 corresponds to a file version 302-308 comprising the shared file system 104; the correspondence of symbolic links 436-442 and file versions 302-308 being based on a map entry 352. Second revision information files 450 are initially derived from the first revision information files 354. Each of the second revision information files 450 comprises file revision information corresponding to the symbolic links 436-442 of one or more of a user file system's directory hierarchies 344, 446, 448.

ZHMS works in conjunction with a history managed file system 102. See FIG. 1. A detailed description of a history managed file system 102, colloquially entitled "HMS", follows below. While ZHMS could be configured to work with any history managed file system 102 (such as Hewlett-Packard's "SoftBench CM"), the currently preferred embodiment of ZHMS is specifically designed to work with HMS.

2. Overview of HMS

The following commands describe basic features of

A. HMS(1)

NAME

History Management System--manage RCS, SCCS and BINARY files in a network

DESCRIPTION

The History Management System (HMS) is a set of tools which manage both versioned and nonversioned files in a distributed, networked environment. HMS provides several advantages over direct use of SCCS or RCS, including:

(1) transparent access to files distributed across machines,

(2) multi-platform support (HP-UX, Sun, Domain, SCO Xenix, MS-DOS, . . . )

(3) file references which are independent of storage location,

(4) added/new functionality for SCCS users, commands independent of the underlying control system,

(6) binary file versioning,

(7) time dependency abilities within make(1),

(8) minimal system maintenance.

The remainder of this description is divided into 6 parts: SHARED SOURCE MODIFICATIONS, BASIC CONCEPTS, SITE INSTALLATION, MACHINE INSTALLATION, USER CONFIGURATION, and CONFIGURATION & LOG FILES.

SHARED SOURCE MODIFICATIONS

Some of the material covered in this tutorial is not relevant to shared source:

(1) The HMS server and client programs have been installed on all shared source shadow machines. The master shared source machine, hpfcld, is the only server that will accept source modifications. All other shadow machines will only accept read-only access.

(2) If you wish to access shared source from your own workstation, you will need to install the HMS client programs. Look at the MACHINE INSTALLATION section for more details.

BASIC CONCEPTS

HMS provides a hierarchical view of the files it manages: file paths in HMS have the same syntax as file paths in HP-UX. HMS has its own logical file system, and since this is often confused with the operating system file system, different terms are used in the following discussion. The term project directory is used to refer to HMS directories and the term control file is used when referring to HMS managed files.

HMS is architected in the client-server model. A server is installed on a central machine and manages the HMS database. The clients are installed on all machines, and they interact with the HMS server to perform the HMS operations.

SITE INSTALLATION

Site installation involves several steps. Each is described in detail below. Perform them in the following order:

(1) Choose a machine on which to install the HMS server.

(2) Add the hmgr user to /etc/passwd.

(3) Install the HMS server package on the machine just chosen.

(4) Initialize the HMS server tables.

(5) Add the HMS server to /etc/inittab or /etc/rc.

Choosing the HMS Server Machine

The HMS server machine is the machine which contains (or will contain) all the control files. IL must have disk space for all the control files. CPU power and LAN I/O are the primary performance limiters, though total CPU usage is quite small, except in extreme cases. The recommendation is to choose a quick machine with fast LAN, such as a 9000/720 or 9000/425, but most any HP-UX machine will work.

Adding the hmgr User

Add a pseudo user, hmgr, to the /etc/passwd file. The HMS server program will always run as the user hmgr, and all files managed by HMS will be owned by this user. Any userid (and groupid) number may be chosen, but it should be a number different than any real user. The second field of the hmgr/etc/passwd entry should be `*`. Example entry:

    ______________________________________
             hmgr:*:10000:10000:HMS
             id:/usr/history:/bin/sync
    ______________________________________

    ______________________________________
    ninstall -h hp-gjd -v hmsd
    ______________________________________

    ______________________________________
           hm:23456a:once:sh -c "export TZ;
           TZ=MST7MDT exec /usr/history/hmsd"
    ______________________________________

    ______________________________________
    ninstall -h hp-gjd -v hms
    ______________________________________

    ______________________________________
    # mapdir /<directory.sub.-- path> /<project.sub.-- path>
    mapdir $HOME/work/gjd /gjd
    ______________________________________

    ______________________________________
            #usehost <host> < project.sub.-- path>
            usehost hp-gjd.hp.com /gjd
    ______________________________________

    ______________________________________
            #usetags /<directory.sub.-- path> <tag-list>
            usetags /users/sk/cms
    Tag.sub.-- rev.sub.-- list,defaultRev
    ______________________________________

    ______________________________________
            #logical
                   physical path on disk
            /project
                   /usr/project.sub.-- srcs
            /pro/doc
                   /usr/doc.sub.-- srcs
    ______________________________________

    ______________________________________
    mkdir /usr/project.sub.-- srcs /usr/doc.sub.-- srcs
    chown hmgr /usr/project.sub.-- srcs /usr/doc.sub.-- srcs
    chmod 700 /usr/project.sub.-- srcs /usr/doc.sub.-- srcs
    ______________________________________

    ______________________________________
             cd /usr/history
             fixdb lockinfo outOK outBAD
    ______________________________________

    ______________________________________
    B. FCI(1)
    ______________________________________
    NAME
    fci - file check in - check in new versions of HMS
    files
    SYNOPSIS
    rrev! file›V! ›
    . . .
    ›nN!type ›-cstring! file . . .
    SHARED SOURCE SYNOPSIS
    rtag file RV! ›
    . . .
    rtag -nRCS ›-cstring! file . . .
    fci -NRAW file . . .
    ______________________________________

    ______________________________________
    Options
    ______________________________________
    cstring     Set the RCS comment leader. This option
                is recognized with the -nRCS option.
    hhost       Use the HMS server on host.
    l           Check in file, do not delete the file
                lock, and check out the new version. When
                combined with the -p option, the new
                version is written to standard output.
                Otherwise, the new version is written to
                the local file and left writable.
    mmessage    Use message as the change log.
    ntype       Create new HMS files with versioning
                method of type type. Valid types are BIN,
                RAW (non-versioned), RCS and SCCS.
    Ntype       Install existing RCS and SCCS files into
                HMS. Valid types are RCS and SCCS.
    p           Read data to check in from standard input.
                the -m option is required when this option
                is given.
    q           Perform actions quietly.
    rrev        Set the versions of the checked in file to
                rev. Rev can be a revision number or (BIN
                and RCS types only) a symbolic name.
    R           Recursively check in locked files for
                which a local working copy exists.
    u           Check in file, delete the file lock and
                check out the new version. When combined
                with the -p option, the new version is
                written to standard output. Otherwise,
                the new version is written to the local
                file and left read-only to prevent
                accidental modification.
    V           Print the HMS version string.
    W           Check in file, delete the file lock and
                check out the new version. When combined
                with the -p option, the new version is
                written to standard output. Otherwise,
                the new version is written to the local
                file and left writable, although it cannot
                be checked in without first being locked.
                Be careful with this option.
    ______________________________________

    ______________________________________
    fci /project/boolean.h
    ______________________________________

    ______________________________________
    fci -u /project/README
    ______________________________________

    ______________________________________
            nroff -man foo.1 .vertline. fci -p -m "nroff
            output" bar
    ______________________________________

    ______________________________________
            fci -r REL/8.sub.-- 0
            /hpux/shared/supp/usr/src/cmd/ls.c
    ______________________________________

    ______________________________________
           fci -l -r REL/9.sub.-- 0
           /hpux/shared/supp/usr/src/cmd/more.c
    ______________________________________

    ______________________________________
    fci -nRCS -r REL/8.sub.-- 0
    /hpux/shared/supp/usr/src/cmd/more/main.c
    C. FCO(1)
    NAME
    fco - file check out - check out HMS files
    SYNOPSIS
    rrev! name . . .! ›
    SHARED SOURCE SYNOPSIS
    l!-rrev!›vwMRV! ›
    name . . .
    ______________________________________

    ______________________________________
    Options
    ______________________________________
    ddate      Retrieve the file version as it existed on
               date. The format YY/MM/DD hh:mm:ss is
               recognized by Eco as well as more standard
               formats, such as Feb 21, 1987 23:34:00 and
               11NOV87 21:34.
    f          Enable overwriting of local files which
               are editable (writable). Normally, only
               non-editable (readonly) files will be
               overwritten.
    hhost      Use the HMS server on host.
    l          Retrieve file for modification and create
               an HMS lock against simultaneous
               modifications by others. This option
               enables later use of fci(1) on the file.
    M          Causes local directories to be made as
               necessary.
    n          Print revision information, but do not
               write any files. Useful for simply
               obtaining revision information.
    p          Retrieve file contents to standard output.
    q          Perform actions quietly.
    rrev       Check out the version of the file
               specified. Rev is a number of the form
               "R.L", where R is the major release number
               and L is the level within the release, or
               rev specifies a branch with a number of
               the form "R.L.B.L", where B is the branch.
               If the underlying control system is RCS,
               then rev can also be a symbolic version
               name.
    R          Recursively check out all files in a
               directory. Files are written into
               subdirectories of the local directory as
               appropriate.
    V          Print the HMS version string.
    w          Retrieve file for modification, but do not
               create a lock.
    ______________________________________

    ______________________________________
    fco -MR /project
    ______________________________________

    ______________________________________
             fco -d "April 16,1988 13:30"
             /project/README
    ______________________________________

    ______________________________________
    fco -l -r REL/8.sub.-- 0
    /hpux/shared/supp/usr/src/cmd/ls.c
    D. FDIFF(1)
    NAME
    fdiff - compare HMS file versions
    SYNOPSIS
    V! › rev1 › rev2
    ! ! file . . .
    ______________________________________

    ______________________________________
    Options
    ______________________________________
    b           Cause trailing blanks (spaces and tabs) to
                be ignored and other strings of blanks to
                compare equally. Passed to diff(1).
    c           Perform context diff with 3 lines of
                context. Passed to diff(1).
    C n         Perform context diff with n lines of
                context. Passed to diff(1).
    ddate       Use the HMS file version that was current
                on date.
    e, -f       Produce a script of a, c, and d commands
                for the editor ed(1). Passed to diff(1).
                See diff(1) for details.
    H           Do a fast, half-hearted job. Passed to
                diff(1) as -h.
    hhost       Use the HMS server on host.
    i           Ignore upper/lower case differences.
                Passed to diff(1).
    n           Print revision information on the files,
                but do no check out. Useful for simply
                comparing revisions.
    rrev        Use the HMS file version rev.
    t           Expand tabs in output lines. Passed to
                diff(1).
    w           Ignore all white space (blanks and tabs).
                Passed to diff(1).
    V           Print the HMS version string.
    ______________________________________

    ______________________________________
    fdiff -d "June 15, 1989" /pws/hi
    ______________________________________

    ______________________________________
    Options
    ______________________________________
    ddate       Only print information for versions since
                date.
    E           Only get history about locally existing
                riles.
    hhost       Use the HMS server on host.
    m           Merge the change information for all
                versions of names into one list. The
                output is sorted by time of change, first
                change first. Compare with -t option.
    n           Merge the change information for all
                versions of names into one list. The
                output is sorted by HMS path name.
    rrev        Specify the version of a file to print
                information for. For SCCS versioned
                files, rev must be a single value.
                Information for all versions since and
                including this version will be printed.
                For BIN and RCS typed files, rev can be a
                list of comma-separated versions and
                ranges.
    R           Recursively report on all HMS files found
                in names.
    t           Same as -m, except that the output is
                sorted in reverse order, most recent
                changes first.
    V           Print the HMS version string.
    ______________________________________

    ______________________________________
    u user ! › NRUVX ! ›
    names !
    fl › fls options ! › names !
    fll › fls options ! › names !
    flsf › fls options ! › names !
    flsr › fls options ! › names !
    flsx › fls options ! › names !
    ______________________________________

    ______________________________________
    Options
    There are numerous options:
    1 (one)     The file names will be listed in single
                column format regardless of the output
                device. This will force single column
                format to the user's terminal.
    d           If an argument is a directory, list only
                its name (not its contents); often used
                with -1 to get the status of a directory.
    f           Print information as it is found. Output
                is unsorted, single column format. This
                is useful in shell pipelines as it speeds
                down stream processing. Otherwise all
                information must be gathered before
                anything can be printed.
    hhost       Use the HMS server on host.
    l           List in long format, giving mode, type,
                locks, size in bytes, and time of last
                modification for each file.
    m           Stream output format.
    p           Put a slash (/) after each file name if
                that file is a directory.
    r           Reverse the sort order. This results in
                reverse alphabetic, or, with the -t
                option, the oldest first.
    t           Sort by time modified (latest first)
                instead of by name.
    uuser       Only list files locked by user. This
                option implies -L.
    x           Multi-column output with entries sorted
                across rather than down the page.
    F           Put a slash (/) after each file name if
                that file is a directory, put an asterisk
                (*) after each file name if that file is
                executable, and put an exclamation point
                (|) after each file which is locked. If a
                file is both executable and locked, the
                exclamation point will appear after the
                asterisk.
    L           List only locked files. If long format is
                also specified, the time shown will be the
                lock time rather than the modification
                time.
    N           List mode and time in a numeric format.
                Mode is listed as an octal number and time
                as a decimal number.
    R           Recursively list subdirectories
                encountered.
    U           Only list files owned by self. This
                option implies -L.
    V           Print the HMS version string.
    X           List names in expanded form.
    fls normally is known by several names which provide
    shorthands for the various formats:
    fl is equivalent to fls -m.
    fll is equivalent to fls -1.
    flsf is equivalent to fls -F.
    flsr is equivalent to fls -Rf.
    flsx is equivalent to fls -x.
    ______________________________________

    ______________________________________
            if › "fls -L ${file} 2>/dev/nul'" =
            "${file}"!; then
              echo ${file} is locked.
            fi
    ______________________________________

    ______________________________________
    /usr/lib/terminfo/?/*
                         to get terminal
                         information.
    ______________________________________

    ______________________________________
    Options
    ______________________________________
    hhost        Use the HMS server on host.
    P            Print results to standard output rather
                 than to the working file.
    rrev1        First version. This is required.
    rrev2        Second version. If omitted, the most
                 recent trunk version is assumed.
    ______________________________________

    ______________________________________
    fmerge -p -r1.2 -r1.4 f.c > f.merged.c
    ______________________________________

    ______________________________________
           futil -l -r1.2 f.c
           fci -r1.2.1.1 f.c
           fco -r1.4 f.c
           fmerge -p -r1.2 -r1.2.1.1 f.c >f.merged.c
    ______________________________________

    ______________________________________
    NAME
    futil - perform HMS utility functions
    SYNOPSIS
    tfile! › ›ost! ›
    name . . .
    rrev file . . .
    R! filembol›:›revision!! ›
    . . .
    O -rrev file . . .
    M new.sub.-- dir . . .
    v old.sub.-- file new.sub.-- file
    v file1 ›. . .! dest.sub.-- directory
    ______________________________________

    ______________________________________
    Options
    ______________________________________
    B            Break a lock on a file. If there are
                 multiple locks, use the -r argument to
                 specify which lock to break. This option
                 can be used to delete your own locks, in
                 which case it behaves exactly like the -u
                 option. When breaking anothers' lock, you
                 will be prompted for explanation text
                 which will be included in a mail
                 notification to the lock owner.
    cstring      Set the RCS comment leader to string. The
                 comment leader is printed before every log
                 message line generated by the keyword
                 $Log: futil.1,v $ Revision 1.8 94/05/05
                 11:03:32 11:03:32 hmgr (History Manager)
                 Author: sk@hpfcsa.sde.hp.com update -c
                 string text during check out (see co(1)).
                 This feature is implemented by RCS.
    E            Only perform operation on HMS files for
                 which a local file exists.
    f            Force action without prompting. Useful
                 with -x.
    hhost        Use the HMS database on host.
    l            Create an HMS lock on a version of a file.
                 Specify the version with the -r option.
                 If no version is specified, then the
                 default version is locked.
    mmode        Set the mode of an HMS file. Mode can be
                 numeric or symbolic and supports the same
                 syntax as the chmod(1) command. This
                 option will also set the mode of the local
                 file, and cause future check outs to set
                 this mode. Only the execute bits, and the
                 group and other read bits can be modified.
    M            Create a new HMS directory.
    O            Obsolete revisions in a file. Only
                 supported on RCS file types. The revision
                 range to be obsoleted must be specified in
                 the -r parameter.
    rrev         Specify the version or revision range to
                 operate on.
    R            Operate recursively upon each argument.
    ssymbol ›:›version!!
                 Use to set or clear symbolic symbols in
                 underlying RCS files. To set a symbol,
                 specify symbol:›version!. If version is
                 omitted, symbol will be associated with
                 the latest version on the trunk. If the
                 colon is omitted, then the symbol will be
                 cleared. If the symbol already exists,
                 this command will fail.
    Ssymbol ›:›version!!
                 Same as -s, except that it overrides a
                 previous assignment of symbol.
    tfile        Replace descriptive text in the HMS
                 control file with text from file.
    u            Delete your HMS lock on a file.
    v            Move or rename a file. old-file is
                 renamed to new.sub.-- file. or file1,file2, . . .
                 are moved to the existing dest.sub.-- directory.
    V            Print the HMS version string.
    x            Delete name. If name is a directory, it
                 must be empty. If name is a file, it must
                 not be locked.
    ______________________________________

    ______________________________________
    Options
    ______________________________________
    ddate       Retrieve the file version as it existed on
                date. The format YY/MM/DD hh:mm:ss is
                recognized by fco as well as more standard
                formats, such as Feb 21, 1987 23:34:00 and
                11NOV87 21:34.
    e           Modify the exit status for the case where
                all the files were already up-to-date.
                See DIAGNOSTICS below.
    f           Enable overwriting of local files which
                are editable (writable). Normally, only
                non-editable (read-only) files will be
                overwritten.
    hhost       Use the HMS server on host.
    l           Retrieve file for modification and create
                an HMS lock against simultaneous
                modifications by others. This option
                enables later use of fci(1) on the file.
    n           Print the actions which would be taken,
                but do not execute them.
    pproject    Treat project as the default project.
    q           Perform actions quietly.
    rrev        Check out the version of the file
                specified. Rev is a number of the form
                "R.L", where R is the major release number
                and L is the level within the release, or
                rev specifies a branch with a number of
                the form "R.L.B.L", where B is the branch.
                If the underlying versioning method is BIN
                or RCS, then rev can also be a symbolic
                version name.
    w           Retrieve file for modification, but do not
                create a lock.
    E           Only update existing files. Missing files
                will not be created. The creation of
                directories is controlled by the -M
                option.
    M           Enable creation of missing local
                directories corresponding to existing HMS
                directories.
    R           Recursively retrieve out of date or
                missing files or directories.
    S           Update a shadow copy of the remote HMS
                database. This option causes the control
                files (the SCCS "s." and RCS ",v" files)
                to be retrieved, rather than their
                contents. In addition, the modification
                time of a master control file will be
                propagated to the updated files.
    V           Print the HMS version string.
    ______________________________________

    ______________________________________
            fupdate -R -lr REL/8_0
            /hpux/shared/supp/usr/src/cmd/ksh
    ______________________________________

    ______________________________________
            fupdate -MR
            /hpux/shared/supp/usr/src/cmd/rcs
    ______________________________________

    ______________________________________
    hhost       Synchronize time with host. If not
                specified, the default HMS server is used.
                See hms(1) for more information.
    s           Set the date on the local machine to be in
                sync with the remote machine.
    b           Allows the date to be set backwards as
                well as forward. Must be used with the -s
                option.
    q           Inhibits printing of informational
                messages.
    ______________________________________

    ______________________________________
    hmgr        5050/tcp    # History Management
    System
    ______________________________________

    ______________________________________
    /etc/services
           Should contain an entry for the hmgr services
           with TCP service number of 5050.
    ______________________________________

    ______________________________________
    # zmapdir /user1/project /shared/proj
    ______________________________________

    ______________________________________
    ›ws!#<ws>zhmsview<ws>view.sub.-- name<ws>local.sub.-- dir
    ›<ws>local.sub.-- dir . . .!
    ______________________________________

    ______________________________________
            # zhmsview weekly /user1/project
            # zmapdir /user1/project /shared/proj
    ______________________________________

    ______________________________________
    zco dirx
    ______________________________________

    ______________________________________
    FOR each command argument Name DO
    INITIALIZE num.sub.-- links.sub.-- created = 0;
    ASSIGN local.sub.-- file = absolute.sub.-- path(Name);
    CALL local2remote (local.sub.-- file, remote.sub.-- file,
    remote.sub.-- root, local.sub.-- root);
    ASSIGN remote.sub.-- revinfo.sub.-- summary.sub.-- file = remote.sub.--
    root
    + "/.revinfo/z.sub.-- entire.sub.-- tree";
    ASSIGN local.sub.-- revinfo.sub.-- summary.sub.-- file = local.sub.--
    root
    + "/.revinfo/z.sub.-- entire.sub.-- tree";
    FOR each file recorded in remote.sub.-- revinfo.sub.-- summary.sub.--
    file
    DO
    SET remote.sub.-- modtimes›file! = modification time
    recorded for file;
    SET remote.sub.-- revs›file! = revision designation
    recorded for file;
    END FOR
    FOR each file recorded in local.sub.-- revinfo.sub.-- summary.sub.--
    file
    DO
    SET local.sub.-- modtimes›file! = modification time
    recorded for file;
    SET local.sub.-- revs›file! = revision designation
    recorded for file;
    SET local.sub.-- views›file! = view recorded for file;
    END FOR
    IF remote.sub.-- file is a regular file THEN
    SET list.sub.-- of.sub.-- remotes = remote.sub.-- file;
    ELSE
    IF remote.sub.-- file is a directory THEN
    IF the Recursive option was given THEN
    SET list.sub.-- of.sub.-- remotes to be all non-directories
    in the tree rooted at remote.sub.-- file,
    excluding remote.sub.-- revinfo.sub.-- summary.sub.-- file;
    ELSE
    SET list.sub.-- of.sub.-- remotes to be all non-directories
    contained in remote.sub.-- file;
    END IF
    END IF
    END IF
    FOR each remote.sub.-- file in list.sub.-- of.sub.-- remotes DO
    ASSIGN local.sub.-- file = remote2local(remote.sub.-- file,
            remote.sub.-- root, local.sub.-- root);
    IF remote.sub.-- file NOT IN remote.sub.-- revs THEN
    # Ignore this file, which has not been
    registered for ZHMS fetch
    NEXT remote.sub.-- file;
    END IF
    IF the Force option was not given AND local.sub.-- file is
    writable AND
    local.sub.-- file is not a zymlink THEN
    Issue an error message stating that a writable
    file already exists;
    NEXT remote.sub.-- file;
    END IF
    # Create a zymlink to remote.sub.-- file.
    Remove local.sub.-- file;
    Create a symlink linking local.sub.-- file to remote.sub.-- file,
    creating local directories as necessary;
    SET local.sub.-- modtimes›local.sub.-- file! =
    remote.sub.-- modtimes›remote.sub.-- file!;
    SET local.sub.-- revs›local.sub.-- file! =
    remote.sub.-- revs›remote.sub.-- file!;
    SET local.sub.-- views›local.sub.-- file! = remote.sub.-- root;
    INCREMENT num.sub.-- links.sub.-- created;
    END FOR
    IF (num.sub.-- links.sub.-- created > 0) THEN
    Remove local.sub.-- revinfo.sub.-- summary.sub.-- file;
    FOR local.sub.-- file IN local.sub.-- revs DO
    Record local.sub.-- file, local.sub.-- revs›local.sub.-- file!,
    local.sub.-- modtimes›local.sub.-- file!, and
    local.sub.-- views›local.sub.-- file! in
    local.sub.-- revinfo.sub.-- summary.sub.-- file;
    END FOR
    END IF
    END FOR
    END COMMAND
    # Note: absolute.sub.-- path( ), local2remote( ), and
    remote2local( ) are the same as # described for zupdate.
    ______________________________________

    ______________________________________
           v view!date ›fupdate.sub.-- options! ›
             ›name . . . !
           h host! ›te -a ›-cn! ›
           r rev! ›directory.sub.-- name . . . !
           v view!date -P ›-n! ›
             ›directory.sub.-- name . . . !
    ______________________________________

    ______________________________________
           zrevfupdate -a /shared/proj/daily/dirx
    ______________________________________

    ______________________________________
           zrevfupdate -ac /shared/proj/daily/dirx
    ______________________________________

    ______________________________________
           zrevfupdate -MR -vweekly /shared/proj/weekly
    ______________________________________

    ______________________________________
    FOR each command argument File DO
    OPEN the z.sub.-- entire.sub.-- tree file associated with File
    IF the PseudoRaw option was given THEN
    FOR each file contained in the tree rooted at the
    directory File DO
    IF the file is writable THEN
    Record the file name, a revision designation of
    "PRAW", and file modification time in the
    z.sub.-- entire.sub.-- tree file.
    END IF
    END FOR
    ELSE
    IF File is a directory THEN
    IF the Recursive option was given THEN
    Request the HMS server to conditionally update
    all out-of-date files contained in the tree
    rooted at File.
    ELSE
    Request the HMS server to conditionally update
    all out-of-date files contained in the directory
    File.
    END IF
    END IF
    IF File is a regular file THEN
    Request the HMS server to conditionally update File
    END IF
    FOR each file update reported by the HMS server DO
    Record the file name, revision number, and file
    modification time in the z.sub.-- entire.sub.-- tree file.
    END FOR
    END IF
    CLOSE the z.sub.-- entire.sub.-- tree file associated with File
    END FOR
    END COMMAND
    ______________________________________

    ______________________________________
    v view! ›name . . . !
    ______________________________________

    ______________________________________
              zupdate -R /shared/proj
    ______________________________________

    ______________________________________
              zupdate -RF /shared/proj
    ______________________________________

    ______________________________________
              zupdate -ERF /shared/proj
    ______________________________________

    ______________________________________
              zupdate -Rf -vreleased
    ______________________________________

    ______________________________________
    FOR each command argument Name DO
    INITIALIZE num.sub.-- links.sub.-- updated = 0;
    ASSIGN local.sub.-- file = absolute.sub.-- path(Name);
    CALL local2remote(local.sub.-- file, remote.sub.-- file,
    remote.sub.-- root, local.sub.-- root);
    ASSIGN remote.sub.-- revinfo.sub.-- summary.sub.-- file = remote.sub.--
    root
    + "/.revinfo/z.sub.-- entire.sub.-- tree";
    ASSIGN local.sub.-- revinfo.sub.-- summary.sub.-- file = local.sub.--
    root
    + "/.revinfo/z.sub.-- entire.sub.-- tree";
    FOR each file recorded in remote.sub.-- revinfo.sub.-- summary.sub.--
    file
    DO
    SET remote.sub.-- modtimes›file! = modification time
    recorded for file;
    SET remote.sub.-- revs›file! = revision designation
    recorded for file;
    END FOR
    FOR each file recorded in local.sub.-- revinfo.sub.-- summary.sub.--
    file
    DO
    SET local.sub.-- modtimes›file! = modification time
    recorded for file;
    SET local.sub.-- revs›file! = revision designation
    recorded for file;
    SET local.sub.-- views›file! = view recorded for file;
    END FOR
    IF remote.sub.-- file is a regular file THEN
    SET list.sub.-- of.sub.-- remotes = remote.sub.-- file;
    ELSE
    IF remote.sub.-- file is a directory THEN
    IF the Recursive option was given THEN
            SET list.sub.-- of.sub.-- remotes to be all non-directories
              in the tree rooted at remote.sub.-- file,
              excluding remote.sub.-- revinfo.sub.-- summary.sub.-- file;
    ELSE
            SET list.sub.-- of.sub.-- remotes to be all non-directories
              contained in remote.sub.-- file;
    END IF
    END IF
    END IF
    IF local.sub.-- file is a directory THEN
    IF the Recursive option was given THEN
    SET list.sub.-- of.sub.-- local.sub.-- files to be all files in the
            tree rooted at local.sub.-- file, excluding
            local.sub.-- revinfo.sub.-- summary.sub.-- file;
    SET list.sub.-- of.sub.-- local.sub.-- dirs to be all directories in
            the tree rooted at local.sub.-- file;
    ELSE
    SET list.sub.-- of.sub.-- local.sub.-- files to be all files
            contained in local.sub.-- file;
    SET list.sub.-- of.sub.-- local.sub.-- dirs = local.sub.-- file;
    END IF
    ELSE
    SET list.sub.-- of.sub.-- local.sub.-- files = local.sub.-- file;
    SET list.sub.-- of.sub.-- local.sub.-- dirs = NULL;
    END IF
    FOR each remote.sub.-- file in list.sub.-- of.sub.-- remotes DO
    ASSIGN local.sub.-- file = remote2local(remote.sub.-- file,
    remote.sub.-- root, local.sub.-- root);
    INITIALIZE file.sub.-- is.sub.-- symlink = FALSE;
    INITIALIZE stale.sub.-- link = FALSE;
    INITIALIZE force.sub.-- it = FALSE;
    IF local.sub.-- file exists THEN
    IF local.sub.-- file is a symbolic link THEN
            ASSIGN file.sub.-- is.sub.-- symlink = TRUE;
            IF local.sub.-- views›local.sub.-- file! |= remote.sub.-- root
            THEN
            ASSIGN stale.sub.-- link = TRUE;
    END IF
    ELSE
    IF the ForceWritables option was given OR
            the ForceRead-only option was AND
            local.sub.-- file in not writable THEN
            ASSIGN force.sub.-- it = TRUE;
    END IF
    END IF
    ELSE
    ASSIGN stale.sub.-- link = TRUE;
    END IF
    IF file.sub.-- is.sub.-- symlink OR stale.sub.-- link OR force.sub.-- it
    THEN
    IF remote.sub.-- file IN remote.sub.-- revs THEN
    IF the UpdateDeleted option was not given AND
            remote.sub.-- revs›remote.sub.-- file! is prefixed with
            the string "DELETED.sub.-- "
            THEN
            NEXT remote.sub.-- file;
    ELSE
            DELETE local.sub.-- file from
              list.sub.-- of.sub.-- local.sub.-- files;
    END IF
    ELSE
    # Ignore this file, which has not been
    registered for ZHMS update
    NEXT remote.sub.-- file;
    END IF
    END IF
    IF stale.sub.-- link OR force.sub.-- it OR
    (remote.sub.-- modtimes›remote.sub.-- file! >
    local.sub.-- modtimes›local.sub.-- file! ) THEN
    IF stale.sub.-- link OR force.sub.-- it THEN
    Remove local.sub.-- file;
    Create a symlink linking local.sub.-- file to
    remote.sub.-- file, creating local directories as
    necessary;
    END IF
    SET local.sub.-- modtimes›local.sub.-- file! =
    remote.sub.-- modtimes ›remote.sub.-- file!;
    SET local.sub.-- revs›local.sub.-- file! =
    remote.sub.-- revs›remote.sub.-- file!;
    SET local.sub.-- views›local.sub.-- file! = remote.sub.-- root;
    INCREMENT num.sub.-- links.sub.-- updated;
    END IF
    END FOR
    INITIALIZE num.sub.-- files.sub.-- deleted = 0;
    IF the Exact option was given THEN
    FOR local.sub.-- file IN list.sub.-- of.sub.-- local.sub.-- files DO
              IF local.sub.-- file is a symlink AND
              (local.sub.-- file IN local.sub.-- revs OR
              the AllowSymlinkRemoval option was given)
              THEN
              Remove local.sub.-- file;
              DELETE local.sub.-- revs›local.sub.-- file!
              INCREMENT num.sub.-- files.sub.-- deleted;
            ELSE
              IF the ForceWritables option was given OR
                (the ForceRead-only option was given AND
                local.sub.-- file in not writable) THEN
                Remove local.sub.-- file;
                DELETE local.sub.-- revs›local.sub.-- file!
                INCREMENT num.sub.-- files.sub.-- deleted;
              END IF
            END IF
    END FOR
    FOR local.sub.-- dir IN list.sub.-- of.sub.-- local.sub.-- dirs DO
            IF local.sub.-- dir is empty THEN
              Remove local.sub.-- dir;
            END IF
    END FOR
    END IF
    IF (num.sub.-- links.sub.-- updated > 0) OR (num.sub.-- files.sub.--
    deleted > 0)
    THEN
    Remove local.sub.-- revinfo.sub.-- summary.sub.-- file;
    FOR local.sub.-- file IN local.sub.-- revs DO
            Record local.sub.-- file, local.sub.-- revs›local.sub.-- file!,
            local.sub.-- modtimes›local.sub.-- file!, and
            local.sub.-- views›local.sub.-- file! in
            local.sub.-- revinfo.sub.-- summary.sub.-- file;
    END FOR
    END IF
    END FOR
    END COMNAND
    FUNCTION absolute.sub.-- path(Name)
    RETURN the full path to Name from the root of the file
            system;
    END FUNCTION
    PROCEDURE local2remote(local.sub.-- file, VAR remote.sub.-- file, VAR
                remote.sub.-- root, VAR local.sub.-- root)
    FOR each line of the NappingFile DO
    IF line is a "zmapdir local.sub.-- dir remote.sub.-- dir" line
    THEN
    SET list.sub.-- of.sub.-- remote.sub.-- paths›local.sub.-- dir! =
            remote.sub.-- dir;
    END IF
    IF line is a "zmapview view local.sub.-- dir . . . " line THEN
    FOR each local.sub.-- dir DO
            SET list.sub.-- of.sub.-- views›local.sub.-- dir! view;
    END FOR
    END IF
    END FOR
    IF view was specified as a command option
    "ViewArgument" THEN
    ASSIGN view = ViewArgument;
    ELSE
    ASSIGN view = "daily"
    END IF
    FOR local.sub.-- path IN list.sub.-- of.sub.-- views DO
    IF a leading directory path component prefix of
    local.sub.-- file equals
    local.sub.-- path THEN
    ASSIGN view = list.sub.-- of.sub.-- views›local.sub.-- path!;
    END IF
    END FOR
    FOR local.sub.-- path IN list.sub.-- of.sub.-- remote.sub.-- paths DO
    IF a leading directory path component prefix of
    local.sub.-- file equals local.sub.-- path THEN
    ASSIGN remote.sub.-- root =
    list.sub.-- of.sub.-- remote.sub.-- paths›local.sub.-- path! + "/" +
    view;
    ASSIGN remote.sub.-- file = local.sub.-- file with remote.sub.-- root
            substituted for local.sub.-- path;
    ASSIGN local.sub.-- root = local.sub.-- path;
    BREAK FOR;
    END IF
    END FOR
    END PROCEDURE
    FUNCTION remote2local (remote.sub.-- file, remote.sub.-- root,
    local.sub.-- root)
    RETURN remote.sub.-- file with local.sub.-- root substituted for the
    leading path prefix matching remote.sub.-- root;
    END FUNCTION
    ______________________________________

    ______________________________________
           c type! ›zymlink . . . !
    ______________________________________

    ______________________________________
              fco -rlocal.sub.-- rev zymlink
              touch -tmodtime zymlink
    ______________________________________