|
DataMuseum.dkPresents historical artifacts from the history of: Rational R1000/400 Tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about Rational R1000/400 Tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T V
Length: 56904 (0xde48)
Types: TextFile
Names: »V«
└─⟦d10a02448⟧ Bits:30000409 8mm tape, Rational 1000, ENVIRONMENT, D_12_7_3
└─⟦fc9b38f02⟧ »DATA«
└─⟦9b46a407a⟧
└─⟦12c68c704⟧
└─⟦this⟧
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;