|
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: 45234 (0xb0b2)
Types: TextFile
Names: »V«
└─⟦180fe333a⟧ Bits:30000405 8mm tape, Rational 1000, SW CATALOG, 10_20_0
└─⟦180fe333a⟧ Bits:30000537 8mm tape, Rational 1000, SW Catalog 10_20_0
└─⟦5cb1d1d7f⟧ »DATA«
└─⟦3b1ee7bd8⟧
└─⟦this⟧
with Compilation;
with System_Utilities;
package Local_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_Demotion : Boolean := False;
Allow_Implicit_Accept_Changes : Boolean := True;
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.
-- 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;
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.
-- 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 ingored 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>";
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.
procedure Revert (What_Object : String := "<SELECTION>";
To_Generation : Integer := -1;
Make_Latest_Generation : Boolean := False;
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.
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 <IMAGE_TEXT>,
-- 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>";
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 as the reservation token name.
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_Objects : String := "<SELECTION>";
New_Reservation_Token_Name : String := "<AUTO_GENERATE>";
Comments : String := "";
Work_Order : String := "<DEFAULT>";
Response : String := "<PROFILE>");
-- Make the object(s) in the given working view(s) have a separate
-- reservation. This command severs the relationship between views
-- for objects. When done, the views specified in this command will
-- have their own reservation to share. All other views (not
-- specified) will share a different reservation.
-- A specific reservation token name can be provided, if desired.
procedure Join (What_Object : String := "<SELECTION>";
To_Which_View : String := ">>VIEW NAME<<";
Comments : String := "";
Work_Order : String := "<DEFAULT>";
Response : String := "<PROFILE>");
-- Make object in two or more working views share a reservation. The
-- objects in the views must be identical (textually) and controlled
-- for this command to succeed.
------------------------------------------------------------------------
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. 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
-- SUBSYSTEM.state.configurations.release_name. It also creates an
-- import description file in the same place, named release_name &
-- "_imports". This import description file lists the configuration
-- objects for all views that are imported. It is maintained by
-- all commands that modify or adjust the imports. These two objects
-- are used to reconstruct views from configurations.
-- 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 := "";
Construct_Subpath_Name : Boolean := False;
Create_Spec_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. Units are not complied
-- to a state higher that they were in the source.
-- 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"'
-- 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;
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 := 0;
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.
-- The import description file mentioned in the release command is
-- brought up to date by this command.
-- 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.
------------------------------------------------------------------------
type Subsystem_Type_Enum is (Spec_Load, Combined, System);
procedure Initial (Subsystem : String := ">>SUBSYSTEM NAME<<";
Working_View_Base_Name : String := "Rev1";
Subsystem_Type : Subsystem_Type_Enum :=
Local_Cmvc.Spec_Load;
View_To_Import : String := "";
Model : String := "R1000";
Comments : String := "";
Work_Order : String := "<DEFAULT>";
Volume : Natural := 0;
Response : String := "<PROFILE>");
-- Build a new subsystem 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 subsystem.
------------------------------------------------------------------------
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 Build (Configuration : String := ">>CONFIGURATION NAME<<";
View_To_Import : String := "";
Model : String := "R1000";
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 = "", and if a text file exists with the name "same
-- as configuration_object" & "_imports", that text file is opened
-- after the views are built and imports are constructed from the views
-- or configuration objects named in that file. Please note that copy,
-- initial, import, and remove_import will create and maintain such a
-- text file, so it is probably there.
---------------------------------------------------------------------
-- 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>");
-- In this case, All_Units means all of the units in the current
-- view. Naming a view means all units in that view.
procedure Show_All_Uncontrolled (Object_Or_View : String := "<CURSOR>";
Response : String := "<PROFILE>");
-- List objects that are not controlled. Produces output only if an
-- object listed (or one in the units directory if a view is supplied)
-- is not under CMVC control
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
-- =========== ========== ===== ======== ====== =================
-- UNITS.FOO 5 of 8 VIEW Yes MTD Apr 7, 1987
-- 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.
----------------------------------------------------------------------
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_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 and/or combined views. If a load view is provided, no
-- specs are copied; all specs are copied for combined views.
-- This operation fails if any unit isn't coded, or any spec exists
-- for which a body is required and one doesn't exist.
end Local_Cmvc;