1. Field of the Invention
The present invention relates to a method and a system for providing delta-versioning of data associated with objects. More specifically, the method and system of the present invention provides delta-versioning of data associated with objects stored in a repository in software engineering environments, such as PCTE, wherein data associated with the objects can be stored in files on a host file system. The present invention also allows for delta-versioning of data associated with objects which are arranged in version graphs including multiple predecessor and successor objects.
2. Description of the Prior Art
It is known in software development systems and other file creation systems to provide control of the various versions of documents which are produced. One known document management tool is SCCS (Source Code Control System) which is described in "The Source Code Control System", M. J. Rochkind, National Conference on Software Engineering, 1st proceeding, Washington, D.C., Sep. 11, 1975, pp. 37-43 and in other references. In SCCS, all versions of a source code file are maintained to provide a history of the amendments which have been effected between the original version of a source code file and its most recent version or versions.
One of the disadvantages of maintaining multiple versions of files is the amount of data storage required to store them. In large software development projects, hundreds of versions of various source code files may be created, necessitating large data storage repositories. To reduce the size of the storage repositories which would otherwise be required for storing multiple versions of documents, it is known to employ either forward or reverse delta-versioning.
In forward delta-versioning, a delta control file is created representing the complete first version of a file and "deltas" are added to the control file for each subsequent version. These deltas represent the changes required to convert a previous version of a file to a later version. Once a delta for a subsequent version file has been added to the delta control file, the version file may be removed from the file system as it can be restored, when needed, from the delta control file. As a delta is almost always much smaller than the version file, a significant saving of storage space results.
For example, a delta control file may be created for version 1 of a file and the version 1 file is then deleted. When a new version of the file, version 2, is created the delta control file is updated to include the version 2 delta which contains the changes which were effected to version 1 of the file to obtain version 2. If the user wishes to access version 1, the original version of the file is extracted from the delta control file. If the user wishes to access version 2, the original version is extracted and the changes in the version 2 delta are applied to it to restore version 2 of the file. If, as is often the case, multiple versions have been created and "delta-ed", then the original version is extracted and the changes of each intervening delta are applied, in sequence, to restore the desired version of the file.
Reverse delta-versioning is similar to forward delta-versioning, differing only in that the most recent version of the file is stored in full in the delta control file along with deltas to recreate preceding versions.
Delta-versioning is often implemented as part of a version management tool, such as the above-mentioned SCCS, however this is a problem in that such version management tools are often standalone systems. For example, SCCS is a separate tool from other development tools, such as data modelling, text editing or formatting tools. A user must therefore first invoke the versioning tool to obtain the version of the file desired and then must invoke a separate tool to operate on the recovered version of the file.
In general, the lack of integration between various development tools has been a problem with Computer Aided Software Engineering (CASE) systems. Relatively recently, development tool manufacturers have attempted to define Software Engineering Environments (SEEs) to facilitate the sharing of data between different development tools. One such effort has been made by the European Computer Manufacturers Association (ECMA), which association has defined the Portable Common Tool Environment (PCTE) in the publication, "Portable Common Tool Environment--Abstract Specification", standard ECMA-149, December 1990 and in "Portable Common Tool Environment--C Programming Language Binding", standard ECMA-158, June 1991, the contents of each of which are included herewith by reference.
PCTE is a SEE which comprises a public tool interface, or application program interface (API), and a repository wherein all of the information required in the SEE may be stored. Currently, API's (or bindings) are defined for the C and Ada programming languages, although other API's may well be available in the future.
The information stored in the repository includes software tool programs, data and documents and the public tool interface allows that information to be shared and used by various tools and/or users. In PCTE the repository is object-based, as is described below in more detail.
While PCTE provides for improved sharing of data between tools, problems exist with PCTE and similar systems that employ an object-based repository in that no provisions have been made for delta-versioning of data associated with objects stored in the repository.