MapViewsDoc.tioga
Copyright Ó 1991, 1992 by Xerox Corporation. All rights reserved.
Mike Spreitzer:PARC:Xerox, February 1, 1990
Last tweaked by Mike Spreitzer on July 17, 1990 2:10:38 pm PDT
Willie-s, March 26, 1992 5:09 pm PST
1. MapViews
Etymology
The `X' stands for `eXactly what's in the version maps', and the `A' stands for `All versions in directories given by the version maps'.
The -VerMapX: View
The -VerMapA: is more useful than the -VerMapX: view, but the -VerMapX: view will be described first because it's simpler.
All files that exist in the -VerMapX: view have 3-component names; the first component is the view name (-VerMapX:), the second is the name of a version map (e.g., Source, PSource, or DSource), and the third is a short name (= component) that can be looked up in the named version map. Examples of existing names are (in the standard slashy notation):
`-VerMapX:/Source/Rope.mesa' and
`-VerMapX:/DSource/Tioga.df'.
Examples of names that can't have files associated with them are:
`-VerMapX:/Source/Rope.mesa!3' and
`-VerMapX:/Rope.mesa' and
`-VerMapX:/Object/sun4-o3/RopeImpl.c2c.o'.
The -VerMapX: view cannot do pattern matching on the middle component (because the VersionMap and VersionMapDefaults interfaces do not offer operations that would allow it). That is, one cannot enumerate with a pattern that includes a `*' (or is not a literal for any other reason) in the middle component. Thus, one cannot enumerate `-VerMapX:/*Source/rope.mesa' --- but one can enumerate `-VerMapX:/DSource/*.df'.
File names in the version map views are case-insensitive.
The implementation of the -VerMapX: view uses the version maps to map the given file name to another, and implements the PFS operations on the given files by operations on the files to which they map. For clarity's sake, let's use the adjective `map' for the given names and files, and the adjective `base' for the names and files to which they map. For example, the map name `-VerMapX:/Rope.mesa' maps to the base name `/PCedar2.0/Rope/Rope.mesa!3'.
The map files may not be altered by operations on map files; of course they can be altered by operations on the base files --- but, being ``release'' files, they will usually not change once brought into existence. Thus, map files may not be opened for write, nor may any of their attributes or properties be changed, by operations on map files.
Each map file is attached to its base file. When the base file does not exist in the file system (i.e., has been ``delvered'' since the version maps were made), the map file is a ``broken attachment''.
Since the version maps have only create dates in them, rather than full PFS.UniqueIDs, every map file's UniqueID is of the form [[some gmt, 0], [0, 0]].
Map files always have empty versions. For every shortname ©bar¹ and create date t for which version map Foo has some entries, there will be a map file named ©-VerMapX:/Foo/bar¹ with UID [[t, 0], [0, 0]] attached to a base file named ©d/bar!v¹, where d/bar!v of t is one of those entries in Foo. Thus, if the version maps have entries for one short name and create date in multiple directories, only one entry is revealed through a map file. The order amongst the map files revealed by !l and !h is based entirely on create date --- version parts don't matter (naturally --- they're all empty).
The -VerMapA: View
The -VerMapA: is more useful than the -VerMapX: view, because the version maps are always out of date. The -VerMapA: view differs from the -VerMapX: view in that the -VerMapA: view exposes all existing versions of files revealed by the version map. Thus, `-VerMapA:/Source/MapViewsDoc.Tioga!h' refers to the latest existing version of MapViewsDoc.Tioga (provide that some versions of it are in the Source map), rather than the one existing at the time the version maps were last made.
The files extant in the -VerMapA view have the same three-part name structure as those of the -VerMapX view; they also share the UniqueID restriction, and the inability to pattern-match on the middle component.
Map files always have empty versions. For every shortname ©bar¹ for which version map Foo has some entries, there will be some map files named ©-VerMapA:/Foo/bar¹; when one of those has UID [[t, 0], [0, 0]] and is attached to a base file named ©d/bar!v¹, it is because there is a file named ©d/bar!v¹ in the filsystem, with create date UID [[t, 0], [0, 0]], for some directory d such that Foo has an entry ©d/bar!w¹ (note that v and w are independent). Thus, if there are multiple potential base files with the same shortname and create date, only one is revealed through a map file. The order amongst the map files revealed by !l and !h is based entirely on create date --- version parts don't matter (naturally --- they're all empty).
Using the MapViews
Issue the command `MapViews'; this runs the implementation of both views, and defines some standard prefix map definitions (listed below).
Standard Prefix Map Definitions
pma /r/ -VerMapA:/Source/
pma /p/ -VerMapA:/PSource/
pma /d/ -VerMapA:/DSource/
pma /rx/ -VerMapX:/Source/
pma /px/ -VerMapX:/PSource/
pma /dx/ -VerMapX:/DSource/
pma /VersionMapViewA -VerMapA:/
pma /VersionMapViewX -VerMapX:/
Examples
% ls /r/rope.mesa
/r/
Rope.mesa 20056 23-Feb-89 10:55:34 PST
Rope.mesa 20016 07-Mar-89 13:03:23 PST
-- 2 files, 40072 total bytes
% ls /rx/rope.mesa
/rx/
Rope.mesa 20016 07-Mar-89 13:03:23 PST
-- 1 files, 20016 total bytes
% ls /dx/Tioga*.df
/dx/
Tioga.df 22506 10-Jul-90 17:54:45 PDT
TiogaActive.df 2243 20-Nov-89 20:45:42 PST
TiogaButtons-Source.df 1049 08-Mar-90 16:15:37 PST
TiogaButtons.df 2043 08-Mar-90 16:19:06 PST
TiogaDWIM-Source.df 1334 16-Feb-90 09:08:34 PST
TiogaDWIM.df 4002 25-Apr-90 09:18:58 PDT
TiogaExecCommands.df 4536 19-Sep-89 09:18:08 PDT
TiogaImager.df 2610 17-Apr-90 08:25:44 PDT
TiogaRenumber.DF 1602 23-Nov-88 15:07:56 PST
TiogaStreams-Source.df 776 17-May-90 17:38:18 PDT
TiogaStreams.df 1052 18-May-90 08:30:13 PDT
TiogaTrace.df 1914 24-Apr-90 14:25:46 PDT
TiogaVoice.df 4686 09-May-90 16:37:20 PDT
-- 13 files, 50353 total bytes
% findr SunYP-PCR.df
SunYP-PCR.df =>
[PCedar2.0]<Top>SunYP-PCR.df!12
July 2, 1990 4:55:14 pm PDT
% ls -a /rx/sunyp-pcr.df
/rx/
SunYP-PCR.df 2720 02-Jul-90 16:55:14 PDT
=> /PCedar2.0/Top/SunYP-PCR.df!12
-- 1 files, 2720 total bytes
% ls /r/SunYP-pcr.df
/r/
SunYP-PCR.df 2720 01-Feb-90 12:53:19 PST
SunYP-PCR.df 2720 30-Mar-90 15:14:35 PST
SunYP-PCR.df 2720 02-Jul-90 16:55:14 PDT
-- 3 files, 8160 total bytes
% lsh /r/SunYP-pcr.df
/r/
SunYP-PCR.df 2720 02-Jul-90 16:55:14 PDT
-- 1 files, 2720 total bytes
% open /r/SunYP-source.df
Created Viewer: /r/SunYP-source.df
%
Using VersionMaps in DF files
Say you have version maps, Foo*.VersionMap, in directory /a/b/c/.
% AddVersionMaps Foo /a/b/c/
this will enumerate for /a/b/c/Foo*.VersionMap
Your DF file can have entries like:
ReadOnly [VersionMapViewX]<FooIntermediate>
Fie.mob ~=
Bar.mob ~=
ReadOnly [VersionMapViewX]<FooSource>
Fie.mesa ~=
Bar.mesa ~=
Executable files do not fit this model at the moment.
The ReadOnly is important (but not critical), since version map views are read only; SModel will not even try to write these files (it would fail if it did try). The ~= allows you to use updated version maps.