Version management system using pointers shared by a plurality of versions for indicating active lines of a version

Abstract

A single entity contains source lines, being operated on by one or more end users. Within the same entity are entity version and level control data. Individual source lines contain version-related identification variables. After each version or level update by a user, a comparison is made between new and old versions; source line identification variables are modified, and new source lines are added; dependent version information is stored in the entity, and control data is updated. Subsequent retrievals of a version are responsive to the dependent version information, and produce indications of any changes that had been made to dependent versions.

Claims

What is claimed is:

1. In a programming code development system comprising a CPU, system storage comprising main and auxiliary storage, an application program, and versions of source data in said system storage, said versions having individual data items, an apparatus for providing version management for said source data comprising:

I) a data repository, in said system storage, comprising

a) a control data element comprising one or more version/level control data field pairs, each of said data field pairs uniquely identifying a level of a version of source code and comprising:

i) a version control data element comprising a version identifier identifying one of said versions of source data;

ii) a level control data element comprising a pointer variable field having one or more pointer variables; and

b) one or more data item data elements, each of said data item data elements comprising a prefix field and a data field, said prefix field comprising a single one of said one or more pointer variables, said data field comprising one of said individual data items wherein more than one of said prefix fields have pointer variables in common;

II) an extract means, invocable by said application program, for extracting a specified version level of said versions of source data from said data repository, said extract means comprising Read Control means for obtaining said control data element, and Read Data means for constructing a copy of said specified version level by reading each of said data item data elements and selectively placing a specific one of said data item data elements in said copy if the pointer variable in the prefix area of said specific item data element matches one of said one or more pointer variables in the level control data element paired with the version control data element having the version identifier identifying said specified version.

2. The apparatus of claim 1 in which said version control data element further comprises a version locking flag, and said level control data element further comprises a level locking flag, said apparatus also further comprising a LOCKON/LOCKOFF means, invokable by said application program, for setting and resetting said version locking flag and said level locking flag.

3. The apparatus of claim 2 further comprising:

a) PUT means, invokable by said application program, for copying application-defined data from an input file to said control data element; and

b) GET means, invokable by said application program, for retrieving said application-defined data from said control data element, and placing said application-defined data in a specified output file.

4. The apparatus of claim 1 further comprising store means, invocable by said application program, for storing a changed version of said specified version level into said data repository, and in which said control data element further comprises an identity control element, comprising a highest used pointer variable identifier said highest used pointer variable identifier being updated by said store means on said storing and used by said store means in assigning new pointer variables for said data item data elements.

5. The apparatus of claim 4 in which said store means comprises:

a) compare means for comparing said changed version with said specified version to produce a computer output file;

b) deleted line processing means for updating said data repository in response to an indication of a deleted line in said compare output file; and

c) added line processing means for updating said data repository in response to an indication of an added line in said compare output file.

6. The apparatus of claim 4 in which said version control data element further comprises a base version identifier identifying a base version of said source data upon which said one of said version is based, and a base level change detection (BLCD) list identifying one or more dependent version of said source data potentially affected by a change, in which said store means further comprises BLCD list update means for updating said BLCD list when storing said changed version, and in which said extract means further comprises detection means for detecting said change, by inspecting said BLCD list, when extracting one of said one or more dependent versions from said data repository and returning a notification to said application program.

7. In a programming code development system comprising versions of source data having individual data items, a method for providing version management for said source data comprising the steps of:

a) creating a first version of said source data in a data repository, said first version of said source data comprising a first version control data element and a first set of one or more data item data elements, said first version control data element comprising base level change detection (BLCD) list means for identifying one or more dependent versions of said source data potentially affected by a change to said first version of said source data;

b) creating a second version of said source data, said second version comprising a second version control data element and a second set of one or more data item data elements, said second set including a first subset of said first set so that said second version is dependent on said first version said second version control data element comprising a base version identifier identifying said first version of said source data as being a base version upon which said second version is dependent;

c) modifying a second subset of said first set of individual data items of said first version and storing a resultant modified, first version into said data repository; and

d) scanning all base version identifiers to determine all versions of said source data dependent upon said first version and identifying said second version upon scanning said base version identifier in said second version control data element;

e) placing an indicator of said first version in said BLCD list means of said second version control data element;

f) automatically notifying an accessor, on subsequently accessing said second version and finding said indicator of said first version in said BLCD list means of said second version, of the modifying of said first version.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of software development tools. More particularly, it relates to a system for storing multiple versions of program source data in a single entity, permitting modification to the versions of different accessors.

2. Background Art

Bulk Data Storage Libraries typically serve as large repositories of related data such as source code for a software development project or book versions for a publications organization.

Typically, inherent in these applications is the requirement that multiple versions of source data be maintained and that the versioning technology supports an easily understood, intuitive, view of the data.

Current bulk data storage technologies enable the storage of and retrieval of versions of data via a number of methods:

Full Copy versioning is the most basic implementation of maintaining multiple versions of data. Maintaining multiple full copies of each version of a given source object requires a great deal of storage media (DASD) and is typically applicable only in small bulk data applications where DASD usage is not a problem.

Delta versioning enables multiple changes to be made to a common base and also enables more efficient utilization of DASD. Delta versioning is usually implemented via the creation of multiple small files which represent only the changes (deltas) to a given base version. Delta versioning however, requires the use of unique merge processes in order to initially construct and subsequently reconstruct each given version from the potentially large number of multiple files which make up that version. In addition, the dependency relationships between the multiple files is typically maintained in a separate control file (which must be separately accessed each time a version of the data is to be stored or retrieved). Delta files also require some external mechanism to uniquely identify the line that is to be changed. There are basically two kinds of delta schemes: those in which the full source copy is the oldest version and the deltas represent newer versions; and those in which the full source copy is the newest version and the deltas represent older versions. The former type is sometimes called "forward" deltas whereas the latter are called "reverse" deltas.

Some versioning schemes have been developed which attach line identifiers to each record in a file in order to uniquely identify each line which may be used in a merge operation. However, implementations of this methodology may require the creation and maintenance of multiple separate files (one for each version) in which merge control information is created and maintained. Or Versions Dependencies may not be recordable, or trackable.

Todays information processing applications require greatly enhanced bulk data version control capability coupled with enhanced capability to effectively utilize that data.

Keys areas which must be accessed by these technologies include the following:

The ability to access, control, and modify multiple versions of source data concurrently.

The ability to maintain a history of incremental changes to the source and to uniquely identify the historical order in which changes occur.

The ability to detect, record, and provide notification of changes to a related version.

The ability to maintain control data and source data, and application-defined data in a more intuitive, controlled, and efficient manner.

The ability to minimize the use of external storage (DASD) in facilitating massive data storage requirements.

SUMMARY OF THE INVENTION

This invention provides a new Bulk Data Storage Technology called Single Entity Versioning (SEV).

Using a unique control structure, SEV efficiently enables the storage of multiple versions of source data within the confines of a single entity. SEV accomplishes this via the creation and maintenance of unique version identification and control data which is combined with the source in a fully encapsulated form.

It is an object of this invention to enable the derivation of new source versions from specified existing versions and support the notion of identifying and recording dependent (or related) versions.

It is a further object of this invention to provide a complete history of incremental source change activity identified in the historical order in which the changes occur.

It is another object of this invention to provide means for identifying dependent (or related) versions of bulk data.

It is a further object of this invention to provide the capability of detecting, recording, and providing notification of underlying or related version changes.

It is another object of this invention to provide the capability of recording application defined data within the entity at any specified version level.

It is another object of this invention to provide a serialized access to specified version levels within a source data entity.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart illustrating EXTRACT processing.

FIGS. 2A and 2B are, respectively, top and bottom portions of a flowchart illustrating STORE processing.

FIG. 3 is a flowchart illustrating DELETE LINES processing.

FIG. 4 is a flowchart illustrating ADD LINES processing.

FIG. 5 is a flowchart illustrating Base Level Change Detection Reset operation.

FIG. 6 is a flowchart illustrating the ERASE operation.

FIG. 7 is a flowchart illustrating the PUTDATA operation.

FIG. 8 is a flowchart illustrating the GETDATA operation.

FIG. 9 is a flowchart illustrating the LOCK ON/OFF operation.

FIG. 10 is a control block diagram illustrating the ECD, VCD and LCD structures.

FIG. 11 is a conceptual view of a SEV file, showing sample data and control elements.

FIG. 12 is a block diagram illustrating an example of an iterative series of modifications to a SEV file.

FIG. 13 illustrates a SEV entity upon storing an example version A.

FIG. 14 illustrates a SEV entity upon storing an example version B.

FIG. 15 illustrates a SEV entity upon storing an example version C, change 1.

FIG. 16 illustrates a SEV entity upon storing an example version C, change 2.

DESCRIPTION OF THE PREFERRED EMBODIMENT

From an operational view, SEV is designed to reside `within` a using application. In the preferred embodiment, SEV Functions are invoked by the using application via internal program calls. The following callable functions perform the key function as described:

Extract--Extract a specified version from a SEV file and place it in a display file (from which it may be edited).

and optionally--extract selected User (application-defined) data from a SEV file and place it in a specified receiving file.

Store--Compares the modified file against the prior level file, detects the changes, and builds the new SEV file to be stored.

and optionally--place User data taken from a specified user file into the SEV file to be stored.

Erase--Erases a specified version or modification level from the SEV file.

BLCD Reset--Delete a specified BLCD List entry (which was constructed at the time a file was stored).

LOCKON/LOCKOFF--Sets the on/off "state" of the SEV lock flag in either the VCD or LCD control data areas of the SEV entity. The lock flag is examined by the SEV Extract operation. If the lock flag is "on", the selected version or level will not be extracted, and an appropriate return code is returned to the application.

PUTDATA--copies application-defined data from a specified input file, and records it within the SEV entity at either the ECD, VCD, or LCD control data areas.

GETDATA--retrieves application defined data from either the ECD, VCD or LCD control data areas in the SEV entity, and writes the data to a specified output file.

By way of introduction, the following definitions apply to terms used in this embodiment:

Bulk Data, Source data, or source--The type of data which is typically contained in large files, i.e. program source code, textual data for a book, etc.

Derived Version--References a version of source which is initially derived from a prior version. This is sometimes referred to as a version of source `based on` a prior version.

Underlying/related versions--Source data from which higher versions are derived.

Control Data--Typically data entities which are used to reference or contain processing information about other data.

Timestamp(s)--The use of timestamps is a common practice in may process applications. It is typically used to attach a `date and/or time` specification to an event so that event can be identified by the historical sequence in which it occurred.

Calling/Using Application--SEV is designed to operate as a set of functions which are callable by an application program. SEV functions typically return the SEV output file, data files, and various operational information as defined by the function. All SEV functions return `success/fail` indicators at the completion of each operation.

Edited Text--A reference to a source file which is typically created, viewed, and modified by an end user (i.e. a programmer or a book editor).

Versions--Versions of a source file typically represent iterative changes to a file. New versions of a source file are often derived from a prior version of that file. Each version within SEV may consist of one or more "modification levels" (instances of a version with different timestamps).

SEV file--A SEV file is the working file created and maintained by various functions incorporated in the SEV technology. The SEV file is the Single Entity where multiple versions of source and the control data required to operate on that source is retained.

The SEV Technology utilizes a number of common programming techniques in its preferred embodiment. These techniques are well known and accepted within the professional programming community.

Input/Output processing--Standard I/0 processing is used for all SEV read and write operations. Included is standard I/0 error checking and handling and end of file (EOF) processing.

External Storage Media--The preferred embodiment assumes the use of Direct Access Storage Devices (DASD) as the storage medium. DASD is the common storage medium used in bulk storage (library) applications.

Storage Mapping--This programming technique is used to `map` externally stored data when read into storage for processing. With storage mapping, specific data may be tagged by defined variable names. This technique enables SEV Control Data to be referenced and processed in a consistent manner.

Array Processing--This programming technique is used to scan data which has been mapped into storage. SEV utilizes standard array processing techniques to search for version pointers, pointer variable list data, control data for SEV built-in functions, etc.

The concept of Pointer Variable Lists is a key methodology which facilitates SEV version processing.

Each time a new source version is created, a new Pointer Variable List is created. Each of these lists contains a sequence of line pointer variables (i.e., line numbers) which collectively constitute a unique version of the source. SEV Pointer Variable Lists are maintained in the Level Control Data (LCD) element. (See FIG. 10.)

When a new modification level is created within an already existing version specification, a new pointer variable list is created and appended to those which already exist in that versions LCD element. This feature provides the capability of uniquely identifying each incremental modification level of the source so that it may be saved and subsequently accessed.

A key feature of SEV uniquely identifies each version of a source object stored in a SEV file. By attaching a timestamp to each Pointer Variable List, SEV enables each version to be uniquely identified in the historical order in which it was created.

The following is a description of the SEV Control Line constructs.

The basic SEV Control Line structure consists of three Control Data Elements:

Entity Control Data (ECD)--Identifies Entity level data, the HILINE value--i.e., the highest currently assigned line number and optional application defined data. There is only one ECD element per SEV entity.

Version Control Data (VCD)--Identifies Version level data, the version/level specification, SEV Base Level Change Detection List, SEV Built In function control variables, and optional application defined data.

Level Control Data (LCD)--Contains the SEV Timestamped Pointer Variable Lists and optional application defined data. Each timestamp in the LCD element corresponds to a specific modification level - or instance of that version.

SEV `ECD` control data (FIG. 10 at 1001) is always the first element in a source entity. There is only one ECD Control Data element per entity. ECD data is followed by additional control data elements depending on the number of versions of the source. The ECD element is used to record entity level SEV control data, it is also used to record application defined data at the entity level (i.e. data that applies to the entity as a whole). The ECD element contains:

a) Application-defined data (1001A)

b) Number of versions in this SEV entity (1001B)

c) Current HILINE identifier (1001C).

SEV `VCD` control data (FIG. 10 at 1002) is always the first of a pair of control data elements (coupled with LCD data) and is used to record unique version control data. The VCD element is also used to record version level application defined data. The VCD element contains:

a) Version identification (1002A)

b) Application-defined data (1002B)

c) Version identifier (1002C)

d) Base identifier (1002D)

e) Lock Flag (1002E)

f) BLCD entry list (1002F)

g) Number of Pointer Variable lists in the following LCD element (1002G).

SEV `LCD` control data (FIG. 10 at 1003) is always the second of a pair of control data elements (coupled with VCD data) and is used to record the SEV Timestamped Pointer Variables Lists. More than one Timestamped Pointer Variable List may exist in an LCD element. This occurs when multiple changes are made to a given version. The actual Timestamped Pointer Variable List(s) are made up of the timestamp (1003C), the number of pointer variables value (1003D) and the pointer variables themselves (from one to many entries) (1003E, F, G). The LCD element contains:

a) Application-defined data (1003A)

b) Lock Flag (1003B)

c) Timestamp value (1003C)

d) Number of Pointer Variables in the following list (here, 3 are illustrated) (1003D)

e) Pointer variable 1 (1003E)

f) Pointer variable 2 (1003F)

g) Pointer variable 3 (1003G).

In a program development environment, one of the most important factors when developing or maintaining multiple levels of dependent source code is the specific knowledge that an underlying (or related) version of the source has been changed. The assumption is that changes to a lower level of source should be forward fitted into the higher level version of the source in order to correctly maintain an orderly development environment. Without this knowledge, there is always the exposure that certain lower level changes (which should be included in the higher version) might go undetected and produce incorrect results. In an environment where multiple versions of source are being altered concurrently by multiple persons, this situation becomes extremely difficult to control.

Base Level Change Detection (BLCD) is a built in function of SEV which automatically detects and records the fact that a dependent version of the source has been changed. There are three basic steps to this process which takes place at the time the version is to be stored.

1. Determine that a version of the source has been changed (per the file compare process).

2. Scan the SEV VCD Control Data to identify any dependent versions (determined by the Base Identifier specification).

3. Record the identity of the changed version in the BLCD list(s) of each version found.

A subsequent access to any higher level version will result in an automatic notification that a base level change was detected and which specific version was actually changed. This information is passed back to the calling application.

Base Level Change Detection utilizes the Version Identifier and the Base Identifier fields in the VCD Control Data elements to determine the chain of dependent versions to be examined.

Note: The Version Identifier is simply a `next sequential` value assigned at the time a new version is created. The Base Identifier points to an underlying/related Version identifier which is specified at the time the new version is created.

For example:

    ______________________________________
          ECD      PARTA.........
                      A  B   C
    1)    VCD      VER.A,01,00,00,00
          LCD      TS1=0001,0002,TS2=0001,0002,0003,0005
                      A  B   C
    2)    VCD      VER.B,02,01,00,01TS2
          LCD      TS1=0001,0002,0003
                      A  B   C
    3)    VCD      VER.C,03,02,00,01TS2
          LCD      TS1=0001,0002,0004
    ______________________________________

    ______________________________________
    Sample Compare Program Output
    Merge file: FILE.A     Target file:FILE.B
    Rel Line #       # of Dels.
                               # of Adds
    ______________________________________
    C     000005                   000002
    LINEA - This line was added
    LINEB - This line was added
    C     000014         000001
    LINEC - This line was deleted
    C     000055         000001    000002
    LINEX - This line was deleted
    LINEY - This line was added
    LINEZ - This line was added
    ______________________________________

• Inventors
  Foster, Richard D.; McCaulley, Ellory K.;
• Assignee
  International Business Machines Corp. (Armonk, NY)
• Published
  Jan-11-1994
• Current US Classes:
  707/203
  715/511
• Application #
  630928
• International Classes
  G06F 007/06
• Field of Search
  395/600 395/100 395/500 395/650
• Examiner
  Lee; Thomas C.
• Agent
  Porter; William B.
• US Patent References:
  4558413
  4714992
  4809170
  4912637
  5133066