Method and system for performing fine grain versioning

Data processing: database and file management or data structures – Database design – Data structure types

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C707S793000, C707S793000, C707S793000, C707S793000, C707S793000, C707S793000, C707S793000

Reexamination Certificate

active

06460052

ABSTRACT:

COPYRIGHT AUTHORIZATION
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent disclosures, as it appears in the U.S. Patent & Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
COMPUTER PROGRAM LISTING APPENDIX ON COMPACT DISC
A computer program listing appendix on compact disc is included as part of this application and the contents of the compact discs are incorporated herein by reference in their entirety for all purposes. The computer program listing appendix includes two compact discs (including duplicates) that are identical copies of each other. Each compact disc contains a file named “AppendixA.txt”, created on Nov. 15, 2001 and having the size of 42,689 bytes.
FIELD OF THE INVENTION
The present invention generally relates to software configuration management systems and more specifically to implementing fine grain versioning within software configuration management systems.
BACKGROUND OF THE INVENTION
Configuration management plays an important role in the development of most software products. In particular, configuration management tools, such as Source Code Control System (SCCS), Revision Control System (RCS) and ClearCase by Atria, provide versioning tools that regulate and manage how software is developed by tracking the updates and modifications that are made to the software components managed by the tools.
For example, in a typical software development project, for a particular product or software release, many different software components may need to be generated. Typically, numerous software developers are involved in the generation of the software components in a software release. To facilitate software development, the software developers are typically allowed to access and modify many of the same software components. To provide for common access, the software components are commonly maintained in a data repository that is accessible by the different software developers. The data repository may reside on a single computer system or may be maintained across multiple computer systems.
For most configuration management systems, such as SCCS, RCS and ClearCase, the versioning tools are file-based and therefore provide versioning at a file level granularity. When a software developer wants to modify a particular software component, he or she is required to “check-out” the file that includes the software component. In checking-out the file, a new “version” of the file is generated and brought into the software developer's current work area. The software developer may then update and modify the file as necessary. Thereafter, the software developer can make the modifications visible to the other software developers by “checking-in” the new file version back into the data repository.
As a file is repeatedly checked out and checked back in, numerous versions of that file will be generated. The files that are versions of a particular file are collectively referred to herein as the “version set” of the file.
A drawback with using a file-based versioning tools is that certain data or information does not fit within the file-based paradigm, and therefore cannot be effectively managed within the configuration management systems that are tied to the file-based paradigm. For example, file-based versioning tools do not provide versioning at finer level of granularity than files, such as versioning of the individual software components within files.
During the first phase of a project, a set of requirements is often generated to ensure that all of the project goals are met. Each requirement may then be mapped to a particular function or software component using a spreadsheet, database or other mapping mechanism. In this manner, the mapping can be performed by linking each spreadsheet cell or table entry with a particular software module. Once the requirements are mapped, a second phase is initiated in which the software developers proceed to develop software components for which the requirements have been mapped. However, because the requirement mapping is performed at the requirement-to-component granularity, and not at a file level granularity, if a software developer determines that a particular requirement should be performed by a different software component, or that a software component should be split into two separate components, the requirement mapping can quickly become outdated as the file-based versioning tool will not maintain a correct mapping.
Another drawback with file-based versioning tools is that they do not support versioning at a level of granularity that is coarser than individual files, such as versioning of groups of related files. For example,
FIG. 1
illustrates a system
100
in which a conventional versioning control mechanism has been implemented. In this example, version sets
104
,
106
,
108
and
110
respectively correspond to files A, B, C and D. As depicted in
FIG. 1
, for many file-based versioning tools, such as RCS or ClearCase, a stripe or label
102
may be generated which includes a particular version of each file within the data repository. The stripe or label
102
may represent a particular product or software release. However, because file-based versioning tools such as RCS or ClearCase can only perform versioning at the file level granularity, to use the strip or label as part of another system, the file versions that belong to the stripe must be manually copied into a separate data repository. Thus, the correlation between the file versions within the stripe or label and the file versions copied into the separate repository are lost.
Based on the foregoing, there is a need to provide a configuration management system in which versioning of software components can be performed at finer and coarser granularities than is provided by the conventional file-based versioning systems.
SUMMARY OF THE INVENTION
The foregoing needs, and other needs and objects that will become apparent from the following description, are achieved in the present invention, which comprises, in one aspect, a method for implementing fine grain versioning within software configuration management systems, the method comprising the computer-implemented steps for converting a non-versioned schema to a version-enabled schema. The method includes reading a first set of table definitions that belong to the non-versioned schema. A second set of table definitions is generated for the version-enabled schema such that each table definition in the second set of table definitions corresponds to a table definition in the first set of table. Each table definition in the second set of table definitions includes columns that correspond to the columns of the corresponding table definition in the first set of table definitions and one or more additional columns for storing version information.
In another aspect, a method for providing version support for objects stored in a relational database system is provided. The method includes creating a table that includes a first set of one or more columns for storing values that correspond to attributes of objects, and a second set of one or more columns for storing object version information. Multiple versions of a particular object are stored within the table. In response to a request from a user to retrieve the particular object, a version of the particular object to present to the user is determined based on a workspace associated with the user. The version of the particular object is presented to the user without exposing values from the second set of one or more columns to the user.
The invention also encompasses a computer-readable medium, and a computer system, configured to carry out the foregoing steps.


REFERENCES:
patent: 5261098 (1993-11-01), Katin et al.
patent: 5467471 (1995-11-01), Bader
patent: 5574898 (1996-11-01), Leblang et al.
patent: 5596714 (1997-01-01), Connell
patent: 5649200 (1997-07-01), Leblang et al.
pate

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Method and system for performing fine grain versioning does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Method and system for performing fine grain versioning, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for performing fine grain versioning will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2989408

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.