DataMuseum.dk

Presents historical artifacts from the history of:

Rational R1000/400 Tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about Rational R1000/400 Tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - download
Index: ┃ T V

⟦dfdfdeb2e⟧ TextFile

    Length: 56904 (0xde48)
    Types: TextFile
    Names: »V«

Derivation

└─⟦d10a02448⟧ Bits:30000409 8mm tape, Rational 1000, ENVIRONMENT, D_12_7_3
    └─ ⟦fc9b38f02⟧ »DATA« 
        └─⟦9b46a407a⟧ 
            └─⟦12c68c704⟧ 
                └─⟦this⟧ 

TextFile

with Compilation;
with System_Utilities;

package Cmvc is

    -- All CMVC commands raise Profile.Error if any error is detected
    -- and Profile.Propagate or Profile.Raise_Error is true

    ------------------------------------------------------------------------

    -- Some of the following reservation commands take the name of an object
    -- that appears in more than one view.  The naming expression
    --      !mumble.subsystem.[view1, view2, view3].units.object
    -- is useful for such times.

    procedure Check_Out (What_Object : String := "<CURSOR>";
                         Comments : String := "";
                         Allow_Implicit_Accept_Changes : Boolean := True;
                         Allow_Demotion : Boolean := False;
                         Remake_Demoted_Units : Boolean := True;
                         Goal : Compilation.Unit_State := Compilation.Coded;
                         Expected_Check_In_Time : String := "<TOMORROW>";
                         Work_Order : String := "<DEFAULT>";
                         Response : String := "<PROFILE>");

    -- Check out reserves one or more objects (specified by What_Object) so
    -- that they may be modified in only one view.  All of the
    -- objects specified must belong to the same working view.
    -- An object must be 'controlled' to be reserved (see Make_Controlled),
    -- a warning is issued for objects that are not controlled.

    -- The reservation spans all of the views that share the
    -- same reservation token for the element.

    -- This command implicitly accepts changes in the checked out object,
    -- updating the value of the object to correspond to the most
    -- recent generation of that element/reservation token pair.
    -- Demotions caused by the implicit accept_changes may be remade to the
    -- goal specified.

    -- The Comments field is stored with the notes for the object.
    -- If What_Object is a set, the comment is stored with all of them.

    -- Expected_Check_In accepts any string that Time_Utilities.Value
    -- will accept.

    procedure Check_In (What_Object : String := "<CURSOR>";
                        Comments : String := "";
                        Work_Order : String := "<DEFAULT>";
                        Response : String := "<PROFILE>");

    -- Release the reservation on the object.  What_Object may
    -- specify a set of objects.  This command only applies to
    -- the controlled objects in the set and will note any
    -- objects that are not controlled.

    -- Comments are treated as in Check_Out



    procedure Accept_Changes
                 (Destination : String := "<CURSOR>";
                  Source : String := "<LATEST>";
                  Allow_Demotion : Boolean := False;
                  Remake_Demoted_Units : Boolean := True;
                  Goal : Compilation.Unit_State := Compilation.Coded;
                  Comments : String := "";
                  Work_Order : String := "<DEFAULT>";
                  Response : String := "<PROFILE>");

    -- This operation updates the Destination to reflect changes
    -- (objects that have been checked in) specified by Source.
    -- Demoted units may be repromoted to the specified goal.

    -- The Destination is either a view or a set of objects (all in
    -- one view).   Specifying the view is equivalent to specifying
    -- all the objects in the view.  Uncontrolled objects in the
    -- destination are ignored except that a note is issued.

    -- The Source is either "<LATEST>", a view, a configuration,
    -- or a set of objects all in one view.

    -- If the Source is "<LATEST>", the destination objects
    -- will be updated to the most recently checked in version.
    -- If the most recent generation of a source object is currently
    -- checked out, the previous generation is used and a warning
    -- is issued.

    -- If the Source is a view and the Destination is a view, this command
    -- is basically "Make the Destination view look exactly like the
    -- Source view".  Every controlled object in the source is copied
    -- to the destination and the configuration in the destination
    -- is updated.  This includes new objects which did not previously
    -- exist in the destination.  If the destination has a more recent
    -- version than the source, the destination will not be updated and
    -- a warning is issued.  In particular, if objects are checked out in
    -- the destination, they will not be changed.
    -- If objects are checked out in the source this operation
    -- will use the previously checked in version of the object and
    -- a warning will be issued.

    -- If the Source is a view and the Destination is a set of objects,
    -- the destination objects are updated to the corresponding objects
    -- in the source view, as above.

    -- If the source is a configuration it is identical to having the
    -- source be a view except that the configuration specifies the
    -- versions to use and they may be older (less up to date) than
    -- the ones in the destination.  Thus if the source is a configuration
    -- then destination objects may "go backwards", while this will not
    -- happen if the source is a view.

    -- If the source is a set of objects and the destination is a view,
    -- the corresponding objects in the destination view are updated
    -- to the source objects.

    -- A common way of using  Accept_Changes is to use the default parameters
    -- during normal development to accept changes made in other subpaths.
    -- Then periodically an integration view (in the path) is updated by
    -- first accepting all relevant subpaths into the integration view
    -- (accept_changes (destination => integration_view, source =>
    -- active_subpath_working_view)).
    -- Then this integration view is compiled (and tested).  The subpaths are
    -- then re-synchronized by accepting the integration view (source =>
    -- integration_view, destination => destination_subpath_working_view).

    -- In addition to synchronizing the source, this protocol updates
    -- the libraries in such a way the relocation operates most effectively,
    -- preventing compilation in many cases when changes move between views.

    procedure Abandon_Reservation
                 (What_Object : String := "<SELECTION>";
                  Allow_Demotion : Boolean := False;
                  Remake_Demoted_Units : Boolean := True;
                  Goal : Compilation.Unit_State := Compilation.Coded;
                  Comments : String := "";
                  Work_Order : String := "<DEFAULT>";
                  Response : String := "<PROFILE>");

    -- Forget about a check_out of some object, or set of objects.
    -- This reverts the objects back to last checked in version.
    -- This operation is an "undo" for Check_Out, except that it
    -- does not undo the implict Accept_Changes that goes with
    -- a Check_Out.  Demoted units may be repromoted to the specified goal.

    procedure Revert (What_Object : String := "<SELECTION>";
                      To_Generation : Integer := -1;
                      Make_Latest_Generation : Boolean := False;
                      Allow_Demotion : Boolean := False;
                      Remake_Demoted_Units : Boolean := True;
                      Goal : Compilation.Unit_State := Compilation.Coded;
                      Comments : String := "";
                      Work_Order : String := "<DEFAULT>";
                      Response : String := "<PROFILE>");

    -- Replace the contents of the specified object with the contents
    -- of the specified generation.  The operation is equivalent to an
    -- Accept_Changes from a configuration containing the specified
    -- generation.

    -- If Make_Latest_Generation is true, then the operation is equivalent to
    -- a Check_Out, a copy of the specified generation into the object, and
    -- a Check_In.

    -- Generation of -n means n generations back; thus -1 => the previous
    -- generation.

    ------------------------------------------------------------------------


    -- The following commands allow the creation and interogation of
    -- a note scratchpad for each element.  Descriptive information
    -- regarding what is being changed, why, or whatever, can be put
    -- into the scratchpad.

    -- The notes for each element can also be manipulated through the
    -- cmvc object editor (see cmvc.notes below).  In most instances
    -- this interface will prove easier to use (for example, the
    -- object need not be checked out to manipulate the notes).


    procedure Get_Notes (To_File : String := "<WINDOW>";
                         What_Object : String := "<CURSOR>";
                         Response : String := "<PROFILE>");

    -- Copy the notes from the object.  If To_File is the default, then
    -- a new I/O window is created and the notes are copied into this window.
    -- The first line of this window is the name of the object, which is
    -- used by Put_ and Append_Notes to put the notes back.  The notes
    -- displayed are those that go with the generation of the object pointed
    -- at.  See Cmvc_History for ways of getting notes and other information
    -- on a range of generations


    -- The next three commands require the object in question to be
    -- checked out.

    procedure Put_Notes (From_File : String := "<WINDOW>";
                         What_Object : String := "<CURSOR>";
                         Response : String := "<PROFILE>");

    -- Replace the notes for the specified object.  If the I/O window
    -- was created by Get_Notes, the window (first line) contains the name
    -- of the object to write back into, and What_Object is ignored.

    procedure Append_Notes (Note : String := "<WINDOW>";
                            What_Object : String := "<CURSOR>";
                            Response : String := "<PROFILE>");

    -- Append the specified text to the notes.  If Note is <WINDOW>,
    -- the associated window must have been created by Get_Notes or
    -- Create_Empty_Note_Window; in this case What_Object is ignored.
    -- If note is a string, then that string is appended to the object
    -- selected by What_Object.  If the content of Note is prepended with a
    -- '_', Note is interpreted as a text file name, and the content of
    -- that file is appended to the selected object.

    procedure Create_Empty_Note_Window (What_Object : String := "<CURSOR>";
                                        Response : String := "<PROFILE>");

    -- Create an empty window (with no underlying directory object)
    -- to be used for constructing notes for the specified object.
    -- Typically, Append_Notes is used to actually add the text
    -- to the object's notes.

    ------------------------------------------------------------------------


    procedure Make_Controlled
                 (What_Object : String := "<CURSOR>";
                  Reservation_Token_Name : String := "<AUTO_GENERATE>";
                  Join_With_View : String := "<NONE>";
                  Save_Source : Boolean := True;
                  Comments : String := "";
                  Work_Order : String := "<DEFAULT>";
                  Response : String := "<PROFILE>");

    -- Make the object or objects specified by What_Object be subject to
    -- reservation.  The objects must be in a working view and not
    -- already controlled.  All objects must be in the same subsystem.
    -- If Join_With_View is specified, the objects are joined with the
    -- object in that view, using the reservation token specified by that view.
    -- If no view is specified, the reservation token name is used if provided,
    -- else the development path name of the view containing the object is
    -- used to compute a new reservation token name.

    -- The value of save_source is meaningful only the first time an
    -- object with a particular name is controlled.  When the first object
    -- with the name is controlled, save_source specifies whether or
    -- not source will be saved in the CMVC database for all objects
    -- with the same name.  When an object with the name has already
    -- been controlled, the value of save_source must agree with the
    -- value that was set for the first such object.
    -- Note that setting save_source to false is the only way to control
    -- files that do not have textual representation.
    -- Also note that when save_source is false the following operations
    -- behave differently:
    --  1. Abandon_Reservation will not revert the object to its previous
    --     state.
    --  2. Check_Out will not cause the object to be updated to the latest
    --     checked in value, unless that value exists in the directory system.
    --  3. Accept_Changes will update the object only if the last checked in
    --     object exists in the directory system.
    --  4. Make_Controlled will not check that the new object being controlled
    --     is equivalent to the last checked in value.


    procedure Make_Uncontrolled (What_Object : String := "<CURSOR>";
                                 Comments : String := "";
                                 Work_Order : String := "<DEFAULT>";
                                 Response : String := "<PROFILE>");

    -- Make an object or objects uncontrolled.
    -- This means the objects are no longer subject to reservation
    -- (in the enclosing view).

    procedure Sever (What_Object : String := "<SELECTION>";
                     New_Reservation_Token_Name : String := "<AUTO_GENERATE>";
                     Comments : String := "";
                     Work_Order : String := "<DEFAULT>";
                     Response : String := "<PROFILE>");

    -- Make the object or objects in the given working view have a separate
    -- reservation.  If multiple objects are specified, all objects must be
    -- in the same view.
    -- A specific reservation token name can be provided or a new token
    -- name will be generated.  Providing a token name is not allowed
    -- to cause implicit joining to other views.

    procedure Join (What_Object : String := "<SELECTION>";
                    To_Which_View : String := ">>VIEW NAME<<";
                    Reservation_Token_Name : String := "";
                    Comments : String := "";
                    Work_Order : String := "<DEFAULT>";
                    Response : String := "<PROFILE>");

    -- Make object in two or more working views share a reservation.  The
    -- objects may either be joined to a specific view or token (but only
    -- one may be specified).  The objects being joined must be identical
    -- to the last checked_in version in each joined set.

    ------------------------------------------------------------------------


    procedure Merge_Changes (Destination_Object : String := "<SELECTION>";
                             Source_View : String := ">>VIEW_NAME<<";
                             Report_File : String := "";
                             Fail_If_Conflicts_Found : Boolean := False;
                             Comments : String := "";
                             Work_Order : String := "<DEFAULT>";
                             Response : String := "<PROFILE>");

    -- Merge two versions of the same object together, leaving the result
    -- in destination object.  In order for this command to succeed, the
    -- Source_View and the view containing the Destination_Object must
    -- have been copied from some common view sometime in the past, and
    -- the configuration for that view must still exist.

    -- Destination_Object must refer to the last generation; all changes must
    -- have been accepted.

    -- The command writes a report showing what it did, as well as changing
    -- the destination object.  If the report_file name is "", the report
    -- is written to Get_Simple_Name (Destination_Object) & "_Merging_Report".

    -- Conflicts are defined to be regions of change in the source and
    -- destination that directly overlap, ie the same line(s) have been
    -- changed in both objects.  If Fail_If_Conflicts_Found is true,
    -- no updating is done, but the report file is left.

    -- If it is desired to rejoin the two objects after the merge, then
    -- check out the Merge source object, copy the Merge Destination_Object
    -- into the source, then Join the objects.

    -----------------------------------------------------------------------

    function Imported_Views (Of_View : String := "<CURSOR>";
                             Include_Import_Closure : Boolean := False;
                             Include_Importer : Boolean := False;
                             Response : String := "<WARN>") return String;

    -- return a string suitable for name resolution that names the union of
    -- all of the imports specified by the view(s) Of_View.  These views
    -- are in no particular order.


    ------------------------------------------------------------------------
    --                               IMPORTS                              --
    ------------------------------------------------------------------------

    -- CMVC supports selective importing of units when views are imported.
    -- This is accomplished using Imports_Restrictions and
    -- Exports_Restrictions.
    --
    -- Exports_Restrictions are subsets of exported Ada units controlled
    -- by the exporting view (spec view).  The subset is determined by the
    -- contents of a text file in the Exports directory of the view.  This
    -- file contains Naming expressions which, when resolved against the
    -- Units directory, produce a list of objects that are exported by
    -- that subset.

    -- Imports_Restrictions are further restrictions on what Ada units are
    -- to be imported.  The restriction specifies which export restriction
    -- to use (if any), a list of Ada units (using simple names) to
    -- exclude, and a list of units to rename.  A restriction is a text
    -- file, in the Imports directory, with the same name as the subsystem
    -- containing the view being imported.  The name of restriction
    -- may either be the simple name of the imported subsystem or the
    -- full name of the subsystem.  If the full name is used, the file
    -- name is formed by taking the path name, removing the leading "!" and
    -- changing all periods to underscores.  If both forms are found
    -- in the same directory, then the full name form takes precedence.
    -- Each line of the file specifies one thing.  The form of the lines are:
    --
    --   EXPORT_RESTRICTION=>restriction_name
    --       Specify the name of the export restriction.  No blanks are
    --       allowed.  If more than one restriction is specified, the
    --       union of all of the restictions is used.
    --   Object_Name     Link_Name
    --       Import Object_Name but make a link with Link_Name (a rename)
    --   ~Object_Name
    --       Dont import Object_Name
    --   Object_name
    --       Import Object_Name and use Object_Name for the link name
    --   @
    --      Import all Objects, except those removed above
    -- In all cases, the names provided above are simple names, ie no '.'s
    -- in them.

    ------------------------------------------------------------------------
    --                          SELECTING VIEWS                           --
    ------------------------------------------------------------------------

    -- In the following commands, wherever a view is called for, a naming set
    -- can be used.   A text file containing the names of configurations
    -- or views can also be used.  However, you must use the leading '_'
    -- convention supported by Naming.  Also, configuration names can be
    -- used in place of views anywhere, assuming that the view represented
    -- by the configuration still exists.


    ------------------------------------------------------------------------
    --                            SPEC VIEWS                              --
    ------------------------------------------------------------------------

    -- Spec views in CMVC are by default uncontrolled.  The reason for this
    -- is to allow free changing of specs in the load views, accepting the
    -- changes back and forth, then incrementally making the changes in the
    -- spec views.

    -- It controlling of spec views is desired, use Make_Controlled after
    -- creating the views.  But be forewarned that checking out a spec
    -- where an implicit accept is required will probably obsolesce all
    -- of the spec's clients.

    ------------------------------------------------------------------------


    procedure Release (From_Working_View : String := "<CURSOR>";
                       Release_Name : String := "<AUTO_GENERATE>";
                       Level : Natural := 0;
                       Views_To_Import : String := "<INHERIT_IMPORTS>";
                       Create_Configuration_Only : Boolean := False;
                       Compile_The_View : Boolean := True;
                       Goal : Compilation.Unit_State := Compilation.Coded;
                       Comments : String := "";
                       Work_Order : String := "<DEFAULT>";
                       Volume : Natural := 0;
                       Response : String := "<PROFILE>");

    -- Create a new release view in the subsystem.  If Release_Name is
    -- "<AUTO_GENERATE>", the view will have the same name prefix as the
    -- working view, with _n_m appended as appropriate given the level.
    -- Otherwise Release_Name must be the simeple name of the new release.

    -- Since the new view is a release, it is frozen.  If From_Working_View
    -- names multiple views, each named working view is released as
    -- above, and the imports are adjusted so that the new releases
    -- reference each other as appropriate instead of the working views.
    -- Views_To_Import specifies, perhaps by indirection through an activity,
    -- a set of views to be used as imports by the new view(s).  This allows
    -- changing imports during a release.  Imports already adjusted during
    -- the releasing of working views will be left alone, otherwise
    -- subsystems currently imported will be reimported.  In other words,
    -- if this were an import command, Only_Change_Imports would be true.

    -- If Compile_The_View is true, the compiler is run before the views
    -- are frozen, trying to promote the units to the indicated Goal.
    -- The views are frozen even if compilation fails.

    -- This command creates a configuration object named release_name
    -- and a state directory named release_name_state.  Both
    -- objects are created in SUBSYSTEM.state.configurations.
    -- The objects can be used by the build command to reconstruct
    -- a view from the released configuration.

    -- A controlled text object (state.release_history) is used by this
    -- command.  Release enters the comments supplied with the command
    -- into the notes for this object.  Feel free to check out and modify
    -- this object to further describe what is going on.  This object is joined
    -- across all of the releases and the working view of a subpath.
    -- Furthermore, the object is checked out and in by the release command
    -- in order to mark the time of the release.


    ------------------------------------------------------------------------


    procedure Copy (From_View : String := "<CURSOR>";
                    New_Working_View : String := ">>SUB/PATH NAME<<";
                    View_To_Modify : String := "";
                    View_To_Import : String := "<INHERIT_IMPORTS>";
                    Only_Change_Imports : Boolean := True;
                    Join_Views : Boolean := True;
                    Reservation_Token_Name : String := "<AUTO_GENERATE>";
                    Construct_Subpath_Name : Boolean := False;
                    Create_Spec_View : Boolean := False;
                    Create_Load_View : Boolean := False;
                    Create_Combined_View : Boolean := False;
                    Level_For_Spec_View : Natural := 0;
                    Model : String := "<INHERIT_MODEL>";
                    Remake_Demoted_Units : Boolean := True;
                    Goal : Compilation.Unit_State := Compilation.Coded;
                    Comments : String := "";
                    Work_Order : String := "<DEFAULT>";
                    Volume : Natural := 0;
                    Response : String := "<PROFILE>");

    -- Create a new working view.   Working views are named Mumble_Working,
    -- where mumble is supplied as New_Working_View.  If Join_Views is
    -- true, the two views share reservations of the all of the controlled
    -- objects in the two views.  If false, reservations aren't shared
    -- across the views for any objects.  If From_View names multiple views, a
    -- copy is made for each of those views and, if the originals
    -- import each other (computed using the subsystem, not the view),
    -- the copies will (try) to import the new views of those subsystems.

    -- If Join_Views is false, new reservation tokens are created for all
    -- of the controlled objects.  The default is to use the name supplied
    -- as the >>SUBPATH_NAME<<.

    -- View_To_Import supplies a set of views to be processed according to
    -- the value of Only_Change_Imports.  If Only_Change_Imports is true,
    -- a copied view always inherits the source view's imports.  After the
    -- copy, the imports specified by View_To_Import are applied against the
    -- new view, replacing any inherited import if needed.
    -- If Only_Change_Imports is false, then either the imports are inherited
    -- from the source, or the complete set of imports specified by
    -- by View_To_Import is imported into the copy.

    -- View_To_Modify specifies the set of working views that are to have
    -- their imports changed to refer to the new copy(s).  The
    -- View_To_Modify views are also changed to refer to the views specified
    -- by View_To_Import.  For this import operation, Only_Change_Imports
    -- is forced to true.

    -- Construct_Subpath_Name cause Copy to contruct the target view name
    -- by appending New_Working_View to the prefix of the source view name
    -- up to the first '_' (See paths and subpaths below).

    -- Remake demoted units, if true, indicates that ada units that were
    -- demoted during the copy process are to be recompiled.  They are
    -- compiled to the level indicated by Goal.

    -- Goal further indicates the desired state of all of the units after
    -- copy.  No unit will be in a state higher than specified by goal, but
    -- might be in a lower state.  For example, a source unit that is copied
    -- will remain source, regardless of Goal, but a Coded unit will be
    -- demoted if Goal is installed or less.

    -- The order of the copy and import operations is:
    --
    --      1.  Create the new view.
    --      2.  If Inherit_Imports, bring along the old imports
    --      3.  Import the new views into the new views, forcing
    --          Only_Change_Imports => True
    --      4.  If not Inherit_Imports, import the specified views
    --          into the new views.
    --      5.  Import the new views + View_To_Import into Views_To_Modify,
    --          forcing Only_Change_Imports => true

    -- Spec views are created by copying the units if the source is a load
    -- view, otherwise using Relocation.  Spec views are created with all
    -- objects uncontrolled.  If level_for_spec_view = natural'last, the
    -- spec view is given the name supplied as new_working_view, otherwise
    -- a name is generated as 'New_Working_View & Release_Numbers & "_spec"'

    -- In a spec_load subsystem, combined views can be created by setting
    -- the create_combined_view parameter.  Combined views are useful in
    -- spec_load subsystems when spec and load views are compiled for the
    -- R1000 target and combined views must be compiled for a different
    -- target that does not support subsystem look-through.

    -- Note that if create_spec_view, create_load_view, and create_combined_view
    -- are all false, then the new view has the same type as from_view.
    -- It is an error to set more that one of these parameters to be true.

    -- It is recognized that this is a complicated command.  Using the
    -- procedures below (which are effectively renames) might make more
    -- sense if the methodolody in use permits it (Path, Subpath, etc).


    ------------------------------------------------------------------------
    --                       PATHS AND SUBPATHS                           --
    ------------------------------------------------------------------------

    -- The following procedures support the notion of paths and subpaths.
    -- A Path is a logically connected series of releases in which all
    -- controlled objects are joined together.  In other words, there is
    -- no branching within a path.  A Subpath is an extension of the
    -- path, allowing multiple developers to make changes and test
    -- without getting in each others way.  However, controlled objects
    -- in the subpaths are joined with the path; people in two subpaths
    -- cannot independently change the same object. In addition, a path
    -- and its subpaths share the same model, which means they share
    -- the same Target_Key and initial links.

    -- In Delta, paths and subpaths are identified by string name conventions.
    -- The name of the path is the view name up to the first '_'.  The
    -- subpath extension is the name from this '_' to the '_Working'. Thus
    -- Rev9_Cbh_Working has a path name of Rev9 and subpath extension of
    -- Cbh.

    -- Multiple paths are used when multiple targets are involved, or when
    -- objects are to be changed independently.  For example, assume that
    -- a version of a product has been shipped, and is in maintenance, and
    -- that development is progessing on a new version.  It is likely that
    -- the old and new versions would be separate paths, since the objects
    -- would have to be independently changed (these paths would not be
    -- 'joined').

    -- In the multiple target case, the paths might be created joined.
    -- Using the above scenario, assume that the release that has been shipped
    -- works on two targets, but most or all of the code is target
    -- independent.  Then the two paths, one for each target, would be
    -- created joined together, then have the objects that are not common
    -- 'Sever'ed.

    procedure Make_Path (From_Path : String := "<CURSOR>";
                         New_Path_Name : String := ">>PATH NAME<<";
                         View_To_Modify : String := "";
                         View_To_Import : String := "<INHERIT_IMPORTS>";
                         Only_Change_Imports : Boolean := True;
                         Create_Load_View : Boolean := False;
                         Create_Combined_View : Boolean := False;
                         Model : String := "<INHERIT_MODEL>";
                         Join_Paths : Boolean := True;
                         Remake_Demoted_Units : Boolean := True;
                         Goal : Compilation.Unit_State := Compilation.Coded;
                         Comments : String := "";
                         Work_Order : String := "<DEFAULT>";
                         Volume : Natural := 0;
                         Response : String := "<PROFILE>");



    procedure Make_Subpath (From_Path : String := "<CURSOR>";
                            New_Subpath_Extension : String := ">>SUBPATH<<";
                            View_To_Modify : String := "";
                            View_To_Import : String := "<INHERIT_IMPORTS>";
                            Only_Change_Imports : Boolean := True;
                            Remake_Demoted_Units : Boolean := True;
                            Goal : Compilation.Unit_State := Compilation.Coded;
                            Comments : String := "";
                            Work_Order : String := "<DEFAULT>";
                            Volume : Natural := 0;
                            Response : String := "<PROFILE>");

    -- The Subpath_Extension is appended to the path name of the source
    -- view (From_Path).  From_Path can actually name the path or any
    -- subpath of the path.  The '_' between the path and subpath extension
    -- is automatically provided.

    procedure Make_Spec_View
                 (From_Path : String := "<CURSOR>";
                  Spec_View_Prefix : String := ">>PREFIX<<";
                  Level : Natural := 1;
                  View_To_Modify : String := "";
                  View_To_Import : String := "<INHERIT_IMPORTS>";
                  Only_Change_Imports : Boolean := True;
                  Remake_Demoted_Units : Boolean := True;
                  Goal : Compilation.Unit_State := Compilation.Coded;
                  Comments : String := "";
                  Work_Order : String := "<DEFAULT>";
                  Volume : Natural := 0;
                  Response : String := "<PROFILE>");

    -- Make a spec view for a path.  Spec_View_Prefix is the string that
    -- replaces the path and subpath name.  For example, if creating a
    -- spec view from a subpath named rev9_cbh_working, with
    -- Spec_View_Prefix => Env9, the result will be Env9_n_Spec, assuming
    -- level => 0 and two levels are specified by the model.  N is a
    -- number automatically generated from the current release number for
    -- the path/subpath.  If level = natural'last, the name supplied as
    -- Spec_View_Prefix is used for the name of the view, with no suffixes

    ----------------------------------------------------------------------


    procedure Import (View_To_Import : String := "<REGION>";
                      Into_View : String := "<CURSOR>";
                      Only_Change_Imports : Boolean := False;
                      Import_Closure : Boolean := False;
                      Remake_Demoted_Units : Boolean := True;
                      Goal : Compilation.Unit_State := Compilation.Coded;
                      Comments : String := "";
                      Work_Order : String := "<DEFAULT>";
                      Response : String := "<PROFILE>");

    -- Imports spec or combined views as appropriate into the specified
    -- view(s).  The import specification can be a set of view names,
    -- in which case all views are imported, unless only_change_imports is
    -- true.  In this case only subsystems that were imported sometime in
    -- the past are reimported.  All others are ignored.

    -- If View_To_Import is "", then the imports of Into_View are refreshed.
    -- This means the various imported views are examined, and any new
    -- Ada specs are imported in to the current view.

    -- It is useful to invoke Import with Views_To_Import = Into_View and
    -- Only_Change_Imports is true.  This will cause a set of views to be
    -- changed to import each other.

    procedure Remove_Import (View : String := ">>VIEW NAME<<";
                             From_View : String := "<CURSOR>";
                             Comments : String := "";
                             Work_Order : String := "<DEFAULT>";
                             Response : String := "<PROFILE>");

    -- remove references to a previously imported view.

    procedure Remove_Unused_Imports (From_View : String := "<CURSOR>";
                                     Comments : String := "";
                                     Work_Order : String := "<DEFAULT>";
                                     Response : String := "<PROFILE>");

    -- Search through all of the Ada units in the view and examine the
    -- withs.  If no units in some imported view are referenced, remove
    -- that import.

    -- This command generates warnings if units in spec or combined
    -- views are referenced, but the view isn't imported.  Errors are
    -- generated if units in load views are referenced.

    procedure Replace_Model (New_Model : String := ">>NEW MODEL NAME<<";
                             In_View : String := "<CURSOR>";
                             Comments : String := "";
                             Work_Order : String := "<DEFAULT>";
                             Response : String := "<PROFILE>");

    -- Replace the model with the new one.  All units must be source.
    -- This command gets the switch file from the new model (if one
    -- was provided), readjusts the maximum levels (which affects future
    -- releases), and rebuilds the links.


    ------------------------------------------------------------------------
    --                           SYSTEM OBJECTS                           --
    ------------------------------------------------------------------------


    type System_Object_Enum is (Spec_Load_Subsystem,
                                Combined_Subsystem, System);

    -- System objects may be either subsystems or systems.  A subsystem
    -- may be either a spec_load_subsystem or a combined_subsystem.

    -- The type of subsystem controls the kinds of views which
    -- the system object may contain.  The subsystem type also controls
    -- whether importing into the subsystem must be hierarchical or
    -- may be non-hierarchical.

    -- Spec_Load subsystems may contain spec views, load views, or
    -- combined views.  All views in spec_load subsystems are
    -- restricted to have only hierarchical imports.  A views imports
    -- are hierarchical if the import closure of the view does not
    -- contain itself.

    -- Combined subsystems may only contain combined views.  The views
    -- in a combined subsystem need not have hierarchical imports.
    -- A view in a combined subsystem may include itself in its
    -- import closure.

    -- Systems contain system views.  Systems are used by Cmvc_Hierarchy
    -- to coordinate the construction of multi-subsystem systems.


    procedure Initial (System_Object : String := ">>SYSTEM OBJECT NAME<<";
                       Working_View_Base_Name : String := "Rev1";
                       System_Object_Type : System_Object_Enum :=
                          Cmvc.Spec_Load_Subsystem;
                       View_To_Import : String := "";
                       Create_Load_View : Boolean := True;
                       Model : String := "R1000";
                       Comments : String := "";
                       Work_Order : String := "<DEFAULT>";
                       Volume : Natural := 0;
                       Response : String := "<PROFILE>");

    -- Build a new system object of the specified type.  Also create a working
    -- view and import as specified.  This command can be used to create
    -- an empty view in an existing system object.  If the system object type
    -- is spec_load_subsystem the new view will be either a load view or a
    -- combined view depending on the value of create_load_view.
    -- While creating the new view directory structure in the model world
    -- will be duplicated in the new view.

    ------------------------------------------------------------------------

    procedure Information (For_View : String := "<CURSOR>";
                           Show_Model : Boolean := True;
                           Show_Whether_Frozen : Boolean := True;
                           Show_View_Kind : Boolean := True;
                           Show_Creation_Time : Boolean := True;
                           Show_Imports : Boolean := True;
                           Show_Referencers : Boolean := True;
                           Show_Unit_Summary : Boolean := True;
                           Show_Controlled_Objects : Boolean := False;
                           Show_Last_Release_Numbers : Boolean := False;
                           Show_Path_Name : Boolean := False;
                           Show_Subpath_Name : Boolean := False;
                           Show_Switches : Boolean := False;
                           Show_Exported_Units : Boolean := False;
                           Response : String := "<PROFILE>");


    -- Show various things about a view.  Please see Cmvc_History for
    -- ways of extracting other information about the controlled objects
    -- in the view.

    ------------------------------------------------------------------------


    procedure Destroy_View (What_View : String := "<SELECTION>";
                            Demote_Clients : Boolean := False;
                            Destroy_Configuration_Also : Boolean := False;
                            Comments : String := "";
                            Work_Order : String := "<DEFAULT>";
                            Response : String := "<PROFILE>");

    -- Destroy a view.  If Demote_Clients is false, the view can have no
    -- referencing views (clients); if it does, the destroy fails.  If
    -- Demote_Clients is true, the view is "remove_import"ed from those
    -- clients (which might cause lots of obsolescence), then the view is
    -- destroyed.  The configuration object for the view is left behind
    -- in its normal place (see Release, above) so the view can be
    -- reconstructed using "Build"

    procedure Destroy_Subsystem (What_Subsystem : String := "<SELECTION>";
                                 Comments : String := "";
                                 Work_Order : String := "<DEFAULT>";
                                 Response : String := "<PROFILE>");

    -- Destroy a subsystem.  There must be no views in the subsystem.

    procedure Destroy_System (What_System : String := "<SELECTION>";
                              Comments : String := "";
                              Work_Order : String := "<DEFAULT>";
                              Response : String := "<PROFILE>");

    -- Destroy a system.  There must be no views in the system.

    ------------------------------------------------------------------------

    procedure Build (Configuration : String := ">>CONFIGURATION NAME<<";
                     View_To_Import : String := "<INHERIT_IMPORTS>";
                     Model : String := "<INHERIT_MODEL>";
                     Goal : Compilation.Unit_State := Compilation.Installed;
                     Limit : String := "<WORLDS>";
                     Comments : String := "";
                     Work_Order : String := "<DEFAULT>";
                     Volume : Natural := 0;
                     Response : String := "<PROFILE>");

    -- Rebuild a view from history.  If Configuration_Object_Name refers to
    -- a text file, that file is assumed to contain a list of configuration
    -- object names to be built.

    -- If View_To_Import = "<INHERIT_IMPORTS>", and if a directory with
    -- the name "same as configuration_object" & "_STATE" exists, that
    -- directory contains state that is used to rebuild the imports.
    -- Note, that the state directory is created by the release command
    -- when a configuration-only release is created.

    ---------------------------------------------------------------------
    --                      HISTORY COMMANDS                           --
    ---------------------------------------------------------------------

    -- The following commands display history information, in various
    -- formats, of Cmvc controlled objects

    procedure Show_History (For_Objects : String := "<CURSOR>";
                            Display_Change_Regions : Boolean := True;
                            Starting_Generation : String := "<CURSOR>";
                            Ending_Generation : String := "";
                            Response : String := "<PROFILE>");

    -- Display the history for the specified objects.  If a view is
    -- specified, all of the controlled objects in that view are displayed.
    -- This history includes notes, checked_out and _in information, and
    -- optionally the actual changes

    -- If display_change_regions is true, the differences between a
    -- generation and the previous one (n-1, n) are displayed.  The display
    -- is in the form of regions where changes occurred similar to that
    -- produced by File_Utilities.Difference(Compressed_Output=>True)

    -- The first generation to display is determined by looking up
    -- the object in the view(s) specified by Starting_Generation.  If
    -- Starting_Generation = "", the display starts at generation 1.

    -- The last generation to display is determined by Ending_Generation.
    -- If E.._G.. is "", the last displayed is the latest one.  If E.._G..
    -- is the name of a view, the generation specified by that view is
    -- used as the last.

    procedure Show_History_By_Generation
                 (For_Objects : String := "<CURSOR>";
                  Display_Change_Regions : Boolean := True;
                  Starting_Generation : Natural := 1;
                  Ending_Generation : Natural := Natural'Last;
                  Response : String := "<PROFILE>");

    -- A form of show_history_by_generation that takes explicit
    -- generation numbers.

    procedure Show_Image_Of_Generation (Object : String := "<CURSOR>";
                                        Generation : Integer := -1;
                                        Output_Goes_To : String := "<WINDOW>";
                                        Response : String := "<PROFILE>");
    -- Reconstruct an image of some generation of the specified object.
    -- The default (-1) indicates back up one generation from that of
    -- Object.  Negative numbers are relative to the generation of Object,
    -- positive numbers are actual generation numbers.
    -- The result is written to current output unless a file name is
    -- supplied in Output_Goes_To.

    ----------------------------------------------------------------------

    -- The following commands produce a report showing objects that
    -- meet some criteria.  This report shows the following information
    -- about each object.

    -- Object Name  Generation  Where  Chkd Out  By Who  Expected Check In  Source Saved
    -- ===========  ==========  =====  ========  ======  =================  ============
    -- UNITS.FOO      5 of 8    VIEW     Yes      MTD    Apr 7, 1987             Yes

    -- Object name is the element name (the name from the view down)

    -- Generation is a pair.  The first number is the generation of
    -- the object used to lookup the element.  The second number is
    -- the highest generation produced.

    -- Where is either the view containing a copy of the last generation
    -- if the object is not checked out, or the view in which the object
    -- is checked out.  In the case where the object is not checked out,
    -- it is possible that there is no representative object, in which
    -- case this field is blank.

    -- Chkd Out is 'Checked Out'.  If this is yes, 'By Who' and
    -- 'Expected Check In' provide more information.

    -- "Source Saved" tells whether or not source is being saved in the
    -- cmvc database for this object.

    ----------------------------------------------------------------------

    procedure Show (Objects : String := "<CURSOR>";
                    Response : String := "<PROFILE>");

    -- Produce the information desribed above for the listed objects.
    -- Also produces a report for each object showing which views
    -- contain elements sharing a reservation token with the object.

    procedure Show_All_Checked_Out (In_View : String := "<CURSOR>";
                                    Response : String := "<PROFILE>");

    -- Look through all of the controlled objects in the supplied view, and
    -- display information about them if they are checked out anywhere

    procedure Show_Checked_Out_In_View (In_View : String := "<CURSOR>";
                                        Response : String := "<PROFILE>");

    -- Display information about all of the objects checked out in the
    -- view pointed at (or in)

    procedure Show_Checked_Out_By_User
                 (In_View : String := "<CURSOR>";
                  Who : String := System_Utilities.User_Name;
                  Response : String := "<PROFILE>");

    -- Display information about any object in the view that is checked out
    -- be the user given.  This command will find the object even if it is
    -- checked out in some other view, as long as it is controlled in the
    -- view referred to.

    procedure Show_Out_Of_Date_Objects (In_View : String := "<CURSOR>";
                                        Response : String := "<PROFILE>");

    -- Display information about all objects in the view that are not
    -- at the latest revision.

    procedure Show_All_Uncontrolled (In_View : String := "<CURSOR>";
                                     Response : String := "<PROFILE>");

    -- Show all uncontrolled objects in the designated view.

    procedure Show_All_Controlled (In_View : String := "<CURSOR>";
                                   Response : String := "<PROFILE>");

    -- Display information about all controlled objects in this view


    ---------------------------------------------------------------------
    --                      ARCHIVE COMMANDS                           --
    ---------------------------------------------------------------------

    procedure Make_Code_View (From_View : String := "<CURSOR>";
                              Code_View_Name : String := "";
                              Comments : String := "";
                              Work_Order : String := "<DEFAULT>";
                              Volume : Natural := 0;
                              Response : String := "<PROFILE>");

    -- Make a code view with the given name.  From_View must only
    -- name load views.  The result is a load view containing an
    -- object called "Code_Database" which contains the executable code for
    -- the units in the from_view.  There are no ada units in
    -- the units directory of the resulting view.
    -- This operation fails if any unit isn't coded, or any spec exists
    -- for which a body is required and one doesn't exist.



    ---------------------------------------------------------------------
    --                     OBJECT EDITOR COMMANDS                      --
    ---------------------------------------------------------------------


    procedure Edit (View_Or_Config : String := "<CURSOR>";
                    In_Place : Boolean := False;
                    Allow_Check_Out : Boolean := True;
                    Allow_Check_In : Boolean := True;
                    Allow_Accept_Changes : Boolean := True);

    -- Brings up the cmvc object editor on the configuration or the
    -- configuration associated with the view.  The view parameter may be a
    -- view itself or any object within a view.

    -- The cmvc object editor display reservation state, object history,
    -- and the notes associated with objects.

    -- The parameters allow_check_out, allow_check_in, and allow_accept_changes
    -- control whether or not these operations can be performed as common
    -- commands in the object editor.


    procedure Notes (What_Object : String := "<CURSOR>";
                     In_Place : Boolean := False);

    -- Brings up the notes for the generation associated with the
    -- specified controlled object.  New notes may be appended.


    procedure Def (What_Object : String := "<CURSOR>";
                   In_Place : Boolean := False);

    -- Used to go between images in the object editor and
    -- objects in the directory system.
    -- When applied to an image in the cmvc object editor, tries
    -- to find the associated object in the directory system.
    -- When applied to a directory object, the cmvc image for that
    -- object is produced.


    ------------------------------------------------------------------------
    --                      VIEW COMPARISON COMMANDS                      --
    ------------------------------------------------------------------------


    procedure Compare (Destination : String := "<CURSOR>";
                       Source : String := "<REGION>";
                       Compare_Both : Boolean := True;
                       Show_New_Uncontrolled : Boolean := True;
                       Show_New_Controlled : Boolean := True;
                       Show_Uncontrolled : Boolean := True;
                       Show_Severed : Boolean := True;
                       Show_Modified : Boolean := True;
                       Show_Equal : Boolean := False;
                       Ada_Units : Boolean := True;
                       Files : Boolean := True;
                       Response : String := "<PROFILE>");

    -- Compare the views.  Destination and Source may be each be
    -- a view or a configuration.  The Ada_Units and Files
    -- parameters determine which type of objects are considered in the
    -- comparison.  The other parameters determine the differences that
    -- are displayed and are dependent on the comparison mode.
    -- Compare_Both determines whether the views are compared symetrically
    -- or whether just the Source is compared against the Destination.
    -- When Compare_Both is false the information is useful in determining
    -- the effect of Cmvc.Accept_Changes from the Source to the Destination.
    --
    -- Compare_Both = True
    -- Show_New_Uncontrolled - Show any objects that are uncontrolled in one
    --                         view but do not exist in the other.
    -- Show_New_Controlled - Show any objects that are controlled in one
    --                       view but do not exist in the other.
    -- Show_Uncontrolled - Show any objects that are uncontrolled in one view
    --                     but which do exist in the other view (either
    --                     controlled or uncontrolled).
    -- Show_Severed - Show any objects that exist in both views,
    --                but are not joined.  This includes objects that
    --                are controlled in one and uncontrolled in the other.
    -- Show_Modified - Show objects that exist and are joined in both views
    --                 but are not the same generation.
    -- Show_Equal - Show the objects that exist in both views are controlled
    --              and joined and have equal generations.
    --
    -- Compare_Both = False
    -- Show_New_Uncontrolled - Show objects in the Source that are uncontrolled
    --                         and do not exist in the destination.
    -- Show_New_Controlled - Show objects in the Source that are controlled
    --                       and do not exist in the Destination.
    -- Show_Uncontrolled - Show objects in the Source that are uncontrolled
    --                     but do exist in the Destination.
    -- Show_Severed - Show objects in the Source view or configuration which
    --                also exist in the Destination but are not joined or
    --                possibly not controlled.
    -- Show_Modified - Show objects in the Source (view or configuration)
    --                 and in the Destination, which are joined but later
    --                 in the source in the Destination.  This may also
    --                 include objects checked out in the source.
    -- Show_Equal - Show objects in the source view or configuration
    --              that also exist with the same generation in the
    --              Destination.
    --
    -- The default parameter settings will display all objects in either
    -- view that have different characteristics than the corresponding
    -- object in the other view.


    procedure Accept_Changes_Effort  
                 (Destination : String := "<CURSOR>";
                  Source : String := "<REGION>";
                  Compare_Both : Boolean := False;
                  Show_New_Uncontrolled : Boolean := False;
                  Show_New_Controlled : Boolean := True;
                  Show_Uncontrolled : Boolean := False;
                  Show_Severed : Boolean := False;
                  Show_Modified : Boolean := True;
                  Show_Equal : Boolean := False;
                  Ada_Units : Boolean := True;
                  Files : Boolean := True;
                  Response : String := "<PROFILE>")  
        renames Compare;

    -- The default parameter settings will display the effect of
    -- Cmvc.Accept_Changes from the Source into the destination.




    pragma Subsystem (Cmvc);
    pragma Module_Name (4, 3704);

end Cmvc;