Method for collapsing a version tree which depicts a history of system data and processes for an enterprise

Abstract

The method of the present invention is useful in a computer system having a user interface, a memory, a database and a repository operative in the computer system for accessing the database. The method is implemented by the computer system for collapsing a version tree that depicts a history of objects stored in the database. The method, which is stored in the memory at run-time, comprises the steps of validating collapse request by insuring that the target object is not a ghost object, the end object is not a ghost, the end object is on the same version tree as the target object, and the end object is a later version than the target object. An empty array representing path objects is initialized from the target object to the end object; and if an end object is supplied, a function is called to build up an array of objects representing paths from the target object to the end object. The array of objects built up in the preceding steps is processed. For each nextVersion of the target object, a function is called to collapse the versions starting from nextVersion; and, a function is also called to destruct the target object.

Claims

What is claimed is:

1. In a computer system having a user interface, a memory, a database and repository operative in said computer system for accessing said database, a method implemented by said computer system for collapsing a version tree that depicts a history of objects stored in said database, said method being stored in said memory at run time and comprising the steps of:

a. validating collapse request by insuring that target object is not a ghost object, the end object is not a ghost, end object is on the same version tree as said target object, and end object is a later version than said target object;

b. initializing an empty array representing path objects from said target object to said end object;

c. if an end object is supplied, calling a function to build up an array of objects representing paths from said target object to said end object, processing said array of objects built up in step c hereof;

d. for each nextVersion of said target object, calling a function to collapse versions starting from nextVersion;

e. calling a function to destruct said target object;

f. for each nextVersion of target object, initializing a continueWalk flag to TRUE;

g. if this nextVersion is in path, setting pathFound to TRUE;

h. if this nextVersion is not in the path, and if variant name of this nextVersion is not the same as the variant name of target object, and if variant name of nextVersion is not the same as variant name of endObject, and if workObject is not the start of a branch, setting continueWalk to FALSE;

i. if this nextVersion is the end object, setting pathFound to TRUE;

j. if this nextVersion is not the end object, and if variant name of this nextVersion is not the same as the variant name of target object, and if variant name of nextVersion is not the same as variant name of endObject, and if workObject is not the start of a branch, setting continueWalk to FALSE;

k. if continueWalk is TRUE, calling a function to continue building a path starting from this nextVersion;

l. if said function returned TRUE, and if this nextVersion is not the endObject, adding this nextVersion to said path;

m. setting pathFound to TRUE;

n. if there are more workObjects, repeating the process steps above until all workObjects have been processed; and,

o. exiting this process and returning a value for pathFound.

2. The method as in claim 1 wherein said step of processing said array further includes the steps of:

a. for each object in the path and for each nextVersion of this path object and if this object is not part of the path, is not later version object and not a result of a merge, calling a function to collapse versions starting from this object;

b. if errors detected, exiting this process;

c. if there are more nextVersions, returning to step a hereof;

d. removing current path object form the path;

e. calling a function to destruct current path object;

f. if errors detected, exiting this process;

and

g. if there are more path objects, repeating all steps hereof until all path objects are processed.

3. The method as in claim 2 further including the steps of:

a. if target object state is readOnly and if remove subbranches was not indicated, prechecking that it is worth continuing recursive walk by;

b. for each nextVersion of target object, if variant name of this object is not the same as variant name of target object, issuing an error and exiting process, returning FALSE; and,

c. if there are more nextVersions, repeating step a hereof until all nextVersions have been processed.

4. The method as in claim 3 further including the steps of:

a. for each nextVersion of target object, if this can be collapsed, calling a function to collapse versions starting from nextVersion of this step;

b. if errors detected, exiting this process returning FALSE; and,

c. if there are more nextVersions, repeating step a hereof until all nextVersions have been processed.

5. The method as in claim 4 further including the steps of:

a. calling a function to destruct current path object;

b. if errors detected, exiting this process returning FALSE;

c. if no errors detected, exiting this process returning TRUE.

6. The method as in claim 2 further including the steps of:

a. if target object state is source and if remove subbranches was not indicated, prechecking that it is worth continuing recursive walk by;

b. for each nextVersion of target object, if variant name of this object is not the same as variant name of target object, issuing an error and exiting process, returning FALSE; and,

c. if there are more nextVersions, repeating step a hereof until all nextVersions have been processed.

7. The method as in claim 6 further including the steps of:

a. for each nextVersion of target object, if this can be collapsed, calling a function to collapse versions starting from nextVersion of this step;

b. if errors detected, exiting this process returning FALSE; and,

c. if there are more nextVersions, repeating step a hereof until all nextVersions have been processed.

8. The method as in claim 7 further including the steps of:

a. calling a function to destruct current path object;

b. if errors detected, exiting this process returning FALSE;

c. if no errors detected, exiting this process returning TRUE.

9. The method as in claim 2 wherein said step of calling a function to collapse versions further includes the steps of:

a. if target object state is available, calling a function to destruct current path object;

b. if there were errors, exiting and returning FALSE; and,

c. if there were no errors, returning TRUE.

10. In a computer system having a user interface, a memory, a database and repository operative in said computer system for accessing said database, a method implemented by said computer system for collapsing a version tree that depicts a history of objects stored in said database, said method being stored in said memory at run time and comprising the steps of:

a. validating a collapse request by insuring that variant name supplied is a viable variant name and earlier version number is non-negative;

b. if collapse request is not valid, exiting this process;

c. initializing to null the earlier and later versioned objects;

d. if later version number is not zero, locating object with specified variant and later version number;

e. if later object not found, issuing an error;

f. if earlier version number is zero, locating root object of specified variant branch;

g. if earlier version number is not zero, locating object at earlier branch and version;

h. sending message to earlier object;

i. specifying later object as end object;

j. validating collapse request by insuring that target object is not a ghost object, the end object is not a ghost, end object is on the same version tree as said target object, and end object is a later version than said target object;

k. initializing an empty array representing path objects from said target object to said end object;

l. if an end object is supplied, calling a function to build up an array of objects representing paths from said target object to said end object, and processing said array of objects built up in this step;

m. for each nextVersion of said target object, calling a function to collapse versions starting from nextVersion;

n. calling a function to destruct said target object; and,

o. exiting the process.

11. The process as in claim 10 wherein said step of calling a function to build further includes the steps of:

a. for each nextVersion of target object, initializing a continueWalk flag to TRUE;

b. if this nextVersion is in path, setting pathFound to TRUE; and,

c. if this nextVersion is not in the path, and if variant name of this nextVersion is not the same as the variant name of target object, and if variant name of nextVersion is not the same as variant name of endObject, and if workObject is not the start of a branch, setting continueWalk to FALSE.

12. The process as in claim 11 further including the steps of:

a. if this nextVersion is the end object, setting pathFound to TRUE; and,

b. if this nextVersion is not the end object, and if variant name of this nextVersion is not the same as the variant name of target object, and if variant name of nextVersion is not the same as variant name of endObject, and if workObject is not the start of a branch, setting continueWalk to FALSE.

13. The method as in claim 12, further including the steps of:

a. if continueWalk is TRUE, calling a function to continue building a path starting from this nextVersion;

b. if said function returned TRUE, and if this nextVersion is not the endObject, adding this nextVersion to said path;

c. setting pathFound to TRUE;

d. if there are more workObjects, repeating the process steps above until all workObjects have been processed; and,

e. exiting this process and returning a value for pathFound.

14. The method as in claim 13 wherein said step of processing said array further includes the steps of:

a. for each object in the path and for each nextVersion of this path object and if this object is not part of the path, is not later version object and not a result of a merge, calling a function to collapse versions starting from this object;

b. if errors detected, exiting this process;

c. if there are more nextVersions, returning to step a hereof;

d. removing current path object form the path;

e. calling a function to destruct current path object;

f. if errors detected, exiting this process; and

g. if there are more path objects, repeating all steps hereof until all path objects are processed.

15. The method as in claim 14 wherein said step of calling a function to collapse versions further includes the steps of:

a. if target object state is available, calling a function to destruct current path object;

b. if there were errors, exiting and returning

FALSE; and,

c. if there were no errors, returning TRUE.

16. The method as in claim 15 further including the steps of:

a. for each nextVersion of target object, if this can be collapsed, calling a function to collapse versions starting from nextVersion of this step;

b. if errors detected, exiting this process returning FALSE; and,

c. if there are more nextVersions, repeating step a hereof until all nextVersions have been processed.

17. The method as in claim 16 further including the steps of:

a. calling a function to destruct current path object;

b. if errors detected, exiting this process

returning FALSE;

c. if no errors detected, exiting this process returning TRUE.

18. The method as in claim 15 further including the steps of:

a. if target object state is readOnly and if remove subbranches was not indicated, prechecking that it is worth continuing recursive walk by;

b. for each nextVersion of target object, if variant name of this object is not the same as variant name of target object, issuing an error and exiting process, returning FALSE; and,

c. if there are more nextVersions, repeating step a hereof until all nextVersions have been processed.

19. The method as in claim 14 further including the steps of:

a. if target object state is source and if remove subbranches was not indicated, prechecking that it is worth continuing recursive walk by;

b. for each nextVersion of target object, if variant name of this object is not the same as variant name of target object, issuing an error and exiting process, returning FALSE; and,

c. if there are more nextVersions, repeating step a hereof until all nextVersions have been processed.

20. The method as in claim 19 further including the steps of:

a. for each nextVersion of target object, if this can be collapsed, calling a function to collapse versions starting from nextVersion of this step;

b. if errors detected, exiting this process returning FALSE; and,

c. if there are more nextVersions, repeating step a hereof until all nextVersions have been processed.

21. The method as in claim 20 further including the steps of:

a. calling a function to destruct current path object;

b. if errors detected, exiting this process returning FALSE;

c. if no errors detected, exiting this process returning TRUE.

22. A process as in claim 10 further including the steps of:

a. if earlier object was not found, issuing an error.

23. A process as in claim 10 further including the steps of:

a. if freeMode is null, setting freeMode to objectOnly; and,

b. if any errors issued, exiting the process.

Description

FIELD OF THE INVENTION

The present invention relates in general to the field of repository databases and in particular to a method for collapsing a version tree representing stored system data and processes for an enterprise.

BACKGROUND OF THE INVENTION

The storage and manipulation of data records or objects within a database application is well known in the prior art. A database allows one to store information in it; and it does not necessarily have any special meaning associated with the things that are stored in the database. A repository not only uses the database as a data store, but it is a layer above a database. A repository has information about the things stored in the database. A repository is like a card catalog that is found in the library, with the library being analogous to the database.

With the advent of repositories, improvements in the accessibility of data within databases has improved. However, as these repositories have become larger and more complex a method is required to not only maintain a history of system data and processes for an enterprise, but also a method for collapsing all or parts of a version tree depicting such history of system data.

The version service enables users to record changes to objects over time and thus to maintain information about the previous states of these objects. Each of these states is maintained in a separate physical object in the repository. As time goes on and the number of evolutionary states of a versionable object increases, it may be desirable to reduce the number of historical states of the object for several reasons. For example, at some point in time a variant branch was created. Over time multiple historical states and later sub-variant branches from this branch were created. Subsequently, it may be determined that this path was only a trial balloon which had no future and there was no need to retain the information on this branch.

In the course of evolving from one state to another, a versionable object actually had many small incremental changes, possibly including branches which were broken out and later merged back into the historical path. When the desired state was finally achieved, it was determined that there was no need to retain all of the interim incremental steps, but only the earlier state and the final state.

The method of the present invention provides the user of the repository with the ability to accomplish the above-stated results with a minimum of operation requests. Moreover, since versioned object destruction is limited to leaf nodes in a version tree, it would not be possible for the user to achieve the same end with a set of calls to destruct individual versioned objects in the tree. The method described hereinafter may be used in one of two different forms. In one form (by identifiers), a message is sent to any object in the version tree and the parameters identify the variant branch to be collapsed (by variant branch name) and the earlier and later versions (by version number). In the second form (by end object), a message is sent to the earlier object and a reference to the later object is passed as a parameter. In both forms, the user indicates whether or not sub-branches may also be removed. If this parameter is FALSE and any sub-branches emanate from any object on the historical path between the earlier and later version, the request fails. If the parameter is TRUE and such sub-branches are encountered, the objects on these sub-branches will be removed along with the objects on the variant branch from the earlier version to the later version.

BRIEF SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide an improvement to a repository system.

It is another object of the present invention to provide an improved repository which supports a method for collapsing a version tree depicting a history of system data and processes in an enterprise.

The method of the present invention is useful in a computer system having a user interface, a memory, a database and a repository operative in the computer system for accessing the database; The method is implemented by the computer system for collapsing a version tree that depicts a history of objects stored in the database. The method comprises the steps of validating a collapse request by insuring that the target object is not a ghost object, the end object is not a ghost, the end object is on the same version tree as the target object, and that the end object is a later version than the target object. Next, an empty array representing path objects from the target object to the end object initialized. If an end object is supplied, a function is called to build up an array of objects representing paths from the target object to the end object. The array of objects built up in the preceding steps is processed. For each nextVersion of the target object, a function is called to collapse versions starting from the nextVersion. A function is called to destruct the target object; and all objects between the target object and the end object are collapsed .

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer system showing the various components of hardware and software that support a repository employing the method of the present invention.

FIG. 2 is a version tree for a versionable repository object called Module.

FIG. 3 is a more complex version tree on which the method of the present invention may also be used.

FIG. 4 is a diagram of the version tree of FIG. 3 illustrating a collapse of variantA.

FIG. 5 is a diagram of the version tree of FIG. 3 illustrating a collapse of variantB.

FIGS. 6A and 6B combined are a flow chart that illustrates the; collapsing of a version tree by providing identifiers.

FIGS. 7A and 7B combined are a flow chart that illustrates the; collapsing of a version tree by providing the end object to the target object.

FIGS. 8A and 8B is a flow chart showing the steps of a; recursive process for building the path to collapse.

FIGS. 9A and 9B is a flow chart showing the steps of; processing the path in collapseVersionsTo.

FIGS. 10A, 10B and 10C combined are a flow chart illustrating the steps of; a recursive process for collapsing versioned objects out of the tree.

DETAILED DESCRIPTION

Before proceeding with a detailed description of the method of the present invention a background discussion of repositories in which the present invention is useful would be helpful. In general, a repository enables the user to store, manage, share and reuse information about the information system in which the repository is used. The repository enables the user to store more than just the data that is processed by an information system. For example, definition data stored in the repository may be information about the development of applications; including descriptions of data, programs and system objects. It may also include information about relationships among data, programs and system objects; as well as the semantics and use of the information.

Examples of definition information might include the files and programs that form a salary administration application. This application might define the minimum and maximum salaries at a given level. Another example is management information used to manage and maintain definition information. Management information also describes who can use definition information and when, where and why the information is used. For example, the salary administration application might be accessible only to a select group of repository users.

Yet another example is operational information about the environment in which the user operates. Examples of this information include system configuration, backup information and schedules.

Referring now to the drawings and FIG. 1 in particular, a block diagram is shown of a computer system 12 including a repository 10 that may use the method of the present invention. The repository 10 is illustrated as being supported by or a part of an information system 12 having a user interface 14. Tools 16-20 (such as CASE tools), which are integrated within the repository 10, are coupled to a services interface 15. The tools 16 and 17 are coupled to the interface 15 by means of an interface agent identified as Portable Common Tool Environment ("PCTE"), tool 18 is coupled to the interface 15 by means of an Information Resource Dictionary System ("IRDS") and tool 20 is coupled to the interface by means of an Electronic Industry Associates ("EIA") interface agent. The point here is to illustrate the flexibility of use of a variety of tools and interface agents with the repository 10.

An administrator 21 manages the repository 10, the database 13 and the environment around the repository. The administrator 21 is typically a work station that can manage a single repository or a network of repositories.

A service library 22 provides the functionality that enables the user to store, manage and reuse repository information. Examples of services within the library 22 are Composite Object Service 22a, which is disclosed in a U.S. Pat. No. 5,557,793 assigned to the assignee of this application and entitled IN AN OBJECT ORIENTED REPOSITORY, A METHOD OF TREATING A GROUP OF OBJECTS AS A SINGLE OBJECT; and MetaData Service 22b, which is disclosed in a copending patent application Ser. No. 08/382,303 also assigned to the assignee of this application and entitled A METHOD FOR SUPPORTING OBJECT MODELING IN A REPOSITORY. Another library service, Persistent Service 22c, deals with definition, tracking and maintenance of objects that continue to exist beyond the execution of a particular tool or of the repository itself. Yet another library service, Version Service 22d, is disclosed in U.S. Pat. No. 5,581,755 assigned to the assignee of this application and entitled A METHOD FOR MAINTAINING A HISTORY OF SYSTEM DATA AND PROCESSES FOR AN ENTERPRISE. The method of the present is a feature of the version service 22d. It is noted that many more types of library services may form a part of such a repository, the details of which are beyond the scope of this disclosure.

The repository employing the present invention provides a client/server architecture in which clients, i.e. tools 16-20, request services form the server, i.e. the repository 10 and its service library 22. In return, the repository and its service library 22 respond to requests from client tools 16-20. A repository client is software that accesses or modifies information that is maintained by the repository. The repository client uses the service library 22 (i.e., the server), which includes software integrated into the repository to manage repository information and provide services to users of that information. It is noted that software in the repository can act both as a repository client when the software is requesting a service from some other repository software and as a repository server when the software is providing a service to some other repository software.

It is pointed out that a SPARC system manufactured by Sun Microsystems, Inc. of Mountain View, Calif., was used for executing one embodiment of the method of the present invention, which method was written in C++ programming language.

As a repository user, one can access the information in the repository through the tools 16-20 that have been integrated within the repository. In the context of a repository, a "tool"is any application software that creates, modifies or uses information in the repository. Tools primarily use the repository for sharing information with other tools and tool users. For example, a COBOL compiler and a user-interface tool can share the definition of a data structure. Tools also benefit from using the repository services that provide features such as a version control and network distribution. A wide variety of tools serving many diverse purposes can use a repository. A catalog of such tools includes integrated computer-aided software engineering (CASE) and fourth generation language (4GL) tools, enterprise modeling tools, analysis and design specification tools, project planning tools, word processors, graphics tools, source code editors, compilers, linkers, debuggers, etc.

The method of the present invention, which is a feature of the version service 22d, enables the user to collapse all or a portion of a version tree within a complex structure previously stored in the repository. The version service 22d enables a user to record changes to objects over time and thus maintain information about the previous states of these objects. In other words, version information provides a history of the system, data and processes for an information system.

At this juncture of the description several definitions would be helpful.

Types

A type is a template that describes a set of features--the state and behavior--that an object or another type can possess. A type defines a pattern that can be used to create or identify objects; it does not contain the actual object. A model is defined by a hierarchy of types.

Most types define the structure of repository objects as the features the objects can have. Data types define the values associated with the features. (Data types are also known as primitive types.) For example, data types are used to define attribute values, operation parameters, and operation return values.

The values represented by the data types do not exist as separate objects in the repository. Instead, they are always sorted as part of a repository object.

Persistent types define objects that continue to exist within the repository beyond the execution of a particular tool or of the repository. These persistent objects are essentially permanent--they remain in the repository until they are explicitly deleted by users. The majority of repository types are persistent.

A transient type defines a temporary object that will be automatically deleted when the function or program in which the object was created exists or terminates. Transient types are provided in the model to support exchange of data between an application and the repository.

A type that can be used to define other types and objects is said to be instantiable. Objects derived from a type are called instances of that type. Types derived from a type are called subtypes of that type. Instances and subtypes of a type inherit the features--attributes, references, and operations--defined for that type. The repository User type is an example of an instantiable type. A type that is used to define only other types and not objects is said to be abstract.

A type that is derived from one or more other types is called a subtype. The definition of a subtype identifies the type or types from which it is derived. A type from which a subtype is derived is called the supertype. The definition of a supertype identifies the subtypes derived from it. A type cannot be a supertype or a subtype of itself. A subtype inherits all the features of its supertype. It can be customized by adding new features. The structure created by deriving types from other types is called a hierarchy. The hierarchy shows the relationship of the supertypes and subtypes.

A hierarchy has a single base type. The base type is the highest supertype in the hierarchy.

In addition to features defined specifically for a subtype, each subtype acquires the features defined for the supertype. This trait is called inheritance. For example, managers have all of the features defined in Manager, and they inherit all of the features of Employee as well. Hence, if the Employee type has a feature such as name, we can ask for the name of a manager since Manager is a subtype of Employee.

Features

A feature defines some element of either the state or the behavior that objects can possess. A feature is defined for a type, but applied to the corresponding objects. The repository has two kinds of features: operations and properties. For example, the Employee type might define the features name, birthDate, salary, and setSalary. Each employee object is subsequently considered to possess these features. That is, each employee has a name, a birth date, and salary. The employee's salary can be modified by using the setSalary feature.

There are two basic categories of features: properties and operations. Properties define state. For example, the salary feature is a property that defines an employee's current salary. Operations define behavior. For example, the setSalary feature is an operation that defines the mechanism for changing an employee's salary.

Properties

A property is a feature that represents a state that objects can possess. (In some models, properties are called instance variables.) A property can represent either a single value or a set of values. Properties are further divided into attributes, whose values are embedded within the owning objects, and references, whose values are independent objects.

The repository supports the following kinds of properties:

Attribute

A property for which the value is embedded within the owning object. For example, an employee's social security number can be defined as an attribute whose value is stored as a string within the employee object.

Reference

A property for which the value is maintained outside the owning object. For example, the employee's manager can be defined as a reference that identifies a separate employee object that represents the manager.

Every property has a domain that identifies the objects that the value of the property can hold. The domain is defined as a type. Objects that are instances of the type are legal values for the property. For example, the domain of the boss property of the Employee type might be specified as the Manager type. Therefore, only a manager object can be designated as the boss of an employee.

When an object is first created, none of its properties have values until they are implicitly assigned a default value or explicitly assigned a value by the construct operation. Until a property has a value it is considered undefined. For properties that are references, the value is considered null. The state of being null is not a value itself. Rather, it means that no value exists.

A property for which the value is embedded within the owning object is called an attribute. Such a property typically is used for simple values that are not shared between multiple owning objects. For example, the Employee property birthDate is simply a Date object--that is, the domain of the birthDate property is the Date type. If one employee's birthDate property is changed, the change does not affect other employees whose birthDate property is the same date. Consequently, each employee object should use a "private" date object that is embedded within it--that is, as an attribute.

A property for which the value is maintained outside the owning object is called a reference. For a reference, the owning object points to the value object. One reason for defining a property as a reference is to allow object sharing. A reference enables two or more owning objects to have the same value for a property. All owning objects can point to the same value object. For example, if two employees have the same manager as a boss, they share the same manager object. Consequently, any changes to the manager (such as changing his or her name) are reflected when the boss reference is accessed for all employees that have that boss.

A property that has one value for each object is said to be single valued. For example, each employee has one name and one birth date. A property that has more than one value for each object is said to be multi-valued. For example, each manager manages multiple employees, so the staff property for a manager object must be able to reference multiple values. A multi-valued property is defined by specifying a collection as its domain. A collection represents a set of values. A collection provides the ability to count the values defined for a multi-valued property, to add new values to the property, and to delete existing values.

The repository supports several types of collections, each of which organizes elements in a different manner. This capability enables the user to:

Store and retrieve the elements in a special order; and,

Search for elements in a special way.

The collection types supported by the repository are summarized in the following table:

                  TABLE I
    ______________________________________
    Type      Description
    ______________________________________
    Array     Creates a dynamic array of objects in which an
              integer index can be used to access array
              members. An array can contain duplicate
              objects.
    List      Creates an ordered collection of objects. A
              list can contain duplicate objects.
    Set       Creates an unordered collection of objects.
              Objects in a set must be unique.
    ______________________________________

                  TABLE II
    ______________________________________
                               Domain/Return
    Type        Feature        Type
    ______________________________________
    Employee    birthDate (attribute)
                               Date
                age (operation)
                               Integer
    ______________________________________

                  TABLE III
    ______________________________________
                         Parameter Parameter
    Operation Parameter  Domain    Options
    ______________________________________
    setSalary amount     Real      REQUIRED
              authorizedBy
                         Manager   REQUIRED
              effective  Date      DEFAULT today's
                                   date
    ______________________________________

                  TABLE IV
    ______________________________________
    Value        Description
    ______________________________________
    available    indicates that the versioned object has no
                 successor objects and therefore can be
                 reserved.
    readOnly     indicates that the versioned object has a
                 successor object on the same variant branch
                 and therefore can be reserved only if the
                 user defines the variant parameter for the
                 reserve operation.
    source       indicates that the versioned object has
                 successor objects, but that none of the
                 successor objects are on the same variant
                 branch as the versioned object. Therefore,
                 the variant name is optional when reserving
                 the object.
    ghost        indicates that the versioned object can be
                 modified. The object is visible only if it
                 is checked out in the current composite
                 context.
    ______________________________________

                  TABLE V
    ______________________________________
    Operation   Description
    ______________________________________
    merge       Checks out a versioned object by merging the
                current versioned object with a designated
                object.
    replace     Checks in a previously reserved versioned
                object and sets the reserveStatus property
                value to available.
    reserve     Checks out a versioned object by creating a
                copy of the object, and sets the
                reserveStatus property value of the copy to
                ghost.
    unreserve   Deletes the ghost object for a previously
                reserved versioned object. If there are no
                more next versions, the operation sets the
                reserveStatus property value of the object to
                available.
    ______________________________________

    ______________________________________
    Reference   Pseudo
    Number      Code
    ______________________________________
    50          Enter
    51          Define a UrepBoolean errorPushed = FALSE
                If variant ==the current variant branch flag
                or variant =="*"(meaning any variant)
                 Issue invalidVariant error and set
                 errorPushed = TRUE
                If earlierVersion < 0
                 Issue invalidEarlierVersion error and
                 set errorPushed = TRUE
    52,53       If errorPushed == TRUE
                Exit
    54          Define null UrepVersionedObjects
                earlierObject and laterObject
    55-58       If laterVersion is not null and
                laterVersion==0
    59-61       If earlierVersion is null or earlierVersion
                = TRUE
                 earlierObject = result of findVersion
                 on "this" and variant
                else
                earlierObject = result of findVersion on
                "this" with parameters earlierVersion and
                variant
    62,63       If earlierObject is null
                 Issue noSuchLaterVersion error and set
                 errorPushed = TRUE
    64,65       If freeMode is null
                 freeMode = objectOnly
    66,67       If errorPushed == TRUE
                 Exit
    68          Call collapseVersionsTo on earlierObject
                with parameters freeMode, laterObject, and
                removeSubbranches
    69          Exit
    ______________________________________

    ______________________________________
    Reference  Pseudo
    Number     Code
    ______________________________________
    70         Enter
    71-73      Define a UrepId myVariantName variantName
               of "this"
               If reserveStatus of "this" == ghost and
               previousVersions of "this" is not null
                Issue notValidForGhost error and exit
               If laterVersion is valid
               Define a UrepBoolean errorPushed = FALSE
               If reserveStatus of laterVersion ==ghost
                Issue cannotCollapseToGhost error and
                set errorPushed = TRUE
               If findRootInternal of "this" |=
               findRootInternal of laterVersion
                Issue differentLogicalObject error and
                set errorPushed = TRUE
               else
               If versionNumber of "this" >= versionNumber
               of laterVersion
                Issue notADescendant error and set
                errorPushed = TRUE
                If errorPushed == TRUE
                Exit
    74         Begin an update transaction
    75         Declare a UrepArray of UrepVersionedObjects
               called path
    76-80      If laterVersion is valid
                Call buildPathRecurse on "this" with
                parameters "this", laterVersion, and
                path (the processPath logic -see next
                process- which is part of this method
                is present here)
               If any errors occurred in the processPath
               logic, the transaction is aborted and this
               process is exited
    81-87      For the number of nextVersions of "this",
               working backwards through the array of
               nextVersions
                If the next nextVersion |= later
                version and the number of
                previousVersions of this next
                nextVersion
               Call collapseVersionRecurse of this next
               nextVersion with parameters myVariantName,
               If the call returns FALSE
                Issue cannotCollapseVersions error
                Abort the update transaction
                Exit
    88         Call destructNode on "this" with parameter
               freeMode
    89         commit the update transaction
    90         Exit
    ______________________________________

    ______________________________________
    Reference Pseudo
    Number    Code
    ______________________________________
    91        Enter
               Declare a UrepBoolean pathFound = FALSE
               Declare a UrepBoolean continueWalk = FALSE
               Declare a UrepId myVariantName = variantName
               of "this"
    92-106     For the number of objects in nextVersions of
               "this"
                continueWalk = TRUE
                Define a UrepVersionedObject workObject
                = the current nextVersion
                If path contains workObject or
                workObject == endOfPath
                 pathFound = TRUE
               else
                If variantName of workObject |=
                myVariantName
                 if variantName or workObject |=
                 variantName of endOfPath
                  If findNext with parameters
                  workObject, searchUp, same
                  variant indicator is valid
                   continueWalk = FALSE
               If continueWalk == TRUE
                Call buildBathRecurse on workObject
                with parameters "this", endOfPath, and
                path
                If the function returns TRUE
                 If workObject |=endOfPath
                  Add workObject to path
                 pathFound = TRUE
    107       Exit, returning pathFound
    ______________________________________

    ______________________________________
    Reference   Pseudo
    Number      Code
    ______________________________________
    108         Enter
    109-120     For the number of objects in path, working
                backwards through the array
                 Define a UrepVersionedObject pathObject
                 = the current path member
                 For the number of nextVersions in
                 pathObject, working backwards through
                 the array
                  Define a UrepVersionedObject
                  workObject = the current
                  nextVersions member
                  If path does not contain
                  workObject and workObject |=later
                  Version and workObject has one
                  previousVersion
                   Call collapseVersionoRecurse
                   on workObject with
                   parameters myVariantName,
                   freeMode and
                   removeSubbranches
                   If the result is FALSE
                    Issue
                    cannotCollapseVersions
                    error
                    Abort the update
                    transaction
                    Exit
    109-120       Capture the current number of
    errors
    Cont'd.       Remove pathObject from path
                 Call destructNode on pathObject with
                 parameter freeMode
                 If there are additional errors
                  Issue cannotCollapseVersions
                  error
                  Abort the update transaction
                  Exit
    121         Exit
    ______________________________________

    ______________________________________
    Reference   Pseudo
    Number      Code
    ______________________________________
    125         Enter
                Define a UrepReserveStatus = myReserveStatus
                of "this"
    126-128     If myReserveStatus == ghost
                 Issue cannotDeleteBranchWithGhost error
                 Exit, returning FALSE
    129-133     If myReserveStatus == available
                Capture the current number of errors
                Call destructNode on "this" with parameter
                freeMode
                If the number of errors increased
                 Exit, returning FALSE
                else
                 Exit, returning TRUE
    134         If myReserveStatus == readOnly or
                myReserveStatus = source
    135-140      If removeSubbranches == FALSE
                  For the number of objects in
                  nextVersions of "this"
                   If variantName of "this" |=
                   variantName of the current
                   nextVersion
                    Issue
                    cannotDeleteBranchWith
                    Subbranches error
                    Exit, returning FALSE
    141-146     For the number of objects in nextVersions of
                "this"
                 Define a UrepVersioned Object
                 workObject = the current nextVersion
    141-146      If the number of previousVersions of
                 workObject == 1 or
                  variantName of this ==
                  variantName of workObject
                  Call collapseVersionsRecurse on
                  workObject with parameters
                  variant, freeMode and
                  removeSubbranches
                  If the result is FALSE
                   Exit, returning FALSE
    147-150     Capture the current number of errors
                Call destructNode on "this" with parameter
                freeMode
                If the number of errors increased
                 Exit, returning FALSE
                else
                 Exit, returning TRUE
    cont'd.
    ______________________________________

• Inventors
  Neubauer, Ronald Jay;
• Assignee
  Unisys Corporation (Blue Bell, PA)
• Published
  Sep-23-1997
• Current US Classes:
  703/23
  707/203
  717/170
• Application #
  470582
• International Classes
  G06F 017/30
• Field of Search
  395/601 395/712 395/619 395/600
• Examiner
  Teska; Kevin J.
• Agent
  Richebourg; J. Ronald, Starr; Mark T., Petersen; Steven R.
• US Patent References:
  4912637
  5303367
  5315709
  5317729
  5347653
  5386559
  5504879
  5557793