Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-11-21
2004-07-20
Robinson, Greta (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
Reexamination Certificate
active
06766334
ABSTRACT:
TECHNICAL FIELD
The invention relates generally to configuration management systems and methods and, more particularly, to systems and methods for reconstructing prior versions of software configurations created in the context of parallel development.
COPYRIGHT NOTICE PERMISSION
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 anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawing hereto: Copyright © 1998, Microsoft Corporation, All Rights Reserved.
BACKGROUND OF THE INVENTION
Many software and Web site applications are created in the context of parallel development, where multiple individuals create and modify numerous files produced by the development language, authoring tool, or application. These projects require processes for versioning source files and for managing changes to the files that comprise the project. Configuration management systems are commonly used for version control and managing changes to file content.
Some configuration management systems merely store copies of the project files at various times. For example, a configuration management system may store the project files for a product release. These complete content configuration copies are then retained in a database for later access, if needed.
One disadvantage to merely copying configurations is that, in a large-scale project, the configuration copies can take up large amounts of disk space. Consequently, a project administrator typically may store relatively few versions of the project (e.g., only particular releases). In some cases, however, it is desirable to have the configuration management system keep track of each project build, where a build could be made as frequently as daily, although builds could be made more or less frequently, as well. A configuration management system that merely copies the database each night would be highly impractical, given the amount of disk space and copying time that would be needed.
More advanced configuration management systems are capable of reconstructing previous project configurations, rather than simply referring to archived copies of specific project configurations. These systems keep track of changes made to the project files, and determine which versions of those files apply to the desired project configuration.
Prior art configuration management systems that can reconstruct previous project configurations typically operate on the individual file level by maintaining a version graph for each file of the project. When a new version of a file is created, the version graph is updated to reflect the new version.
Prior art
FIG. 1
illustrates an example of version graphs for two files, file
1
and file
2
, of a multiple file project in accordance with the prior art. As shown in the Figure, the project has been changed across three project configurations: Configuration A, Configuration B, and Configuration C. For ease of illustration, each version of a file is indicated by a circle
101
,
102
,
103
,
104
,
105
,
106
,
107
,
151
,
152
,
153
,
154
,
155
,
156
, and
157
, and the number within the circle indicates where that particular version fits within the sequence of file versions. Thus, changes were made to file
1
sequentially from
101
-
107
, and circles
101
-
107
represent the first seven versions of file
1
.
The labels “Configuration_” indicate which file versions were created in the context of which project configuration. The version graph
100
for file
1
indicates that three file versions
101
-
103
include changes associated with Configuration A of the project. File versions
104
-
106
include changes associated with Configuration B, and file version
107
includes changes associated with Configuration C. Similarly, the version graph
150
for file
2
indicates that four file versions
151
-
153
and
155
include changes associated with Configuration A. File versions
154
and
156
include changes associated with Configuration B, and file version
157
includes changes associated with Configuration C.
At times, the system may identify certain points along each file's version graph as being part of a specific release. These identifiers are known as labels or configurations. Although multiple versions might have been created in the context of a particular configuration, only those files that are specifically identified as part of a release can later be automatically assembled into a version of the configuration.
Although a version graph may be an effective way to track changes to a particular file,
FIG. 1
illustrates that version graphs fail to establish relationships between the files. Some systems do attempt to manage a collection of related files, but they typically do so in an ad-hoc fashion that is complicated to manage and time consuming to implement. Consider a standard file-oriented configuration management system (such as the UNIX utility RCS), which essentially is a collection of tools that operate on individual files, controlling file access and updates and comparing previous versions. To access and modify a group of files controlled by the system, an individual would need to write a special batch file or specify wildcards on the command line. Thus, the process of accessing the file versions for a particular configuration is a manual one, requiring each individual to have an in-depth knowledge of the project file structure.
Another disadvantage to prior art systems is that, although many systems effectively manage content changes to files, many do not effectively manage namespace changes, such as renaming files and moving files from one drive or folder to another. This inability to effectively manage namespace changes occurs because the filename of each file is generally used as a primary identifier in prior art systems. Thus, if a filename is changed or the file is moved from one drive or folder to another, the configuration management system would behave as if the file was deleted, and a new file was added to the system. In general, no historical link would exist between the previous version of the file, and the renamed or moved file. Even in a system where a historical link would exist, it would not typically be treated as a “first class” change, with the same ability to merge, move, and apply the change as if it were a change to the file's content. Thus, unless an individual knows the name or location of the original file, it would not be possible to trace back and find the original file. This inability of prior art systems to manage namespace changes is particularly problematic for Web site development projects, where namespaces are a primary element of the software system.
A few prior art configuration management systems are project-oriented. One such system is the “MICROSOFT”® “VISUAL SOURCESAFE”™ version control system. Using this system, when an individual retrieves, modifies, and checks a file back in, the system records information indicating that a change to the file content may have occurred. This information is stored in a project history file. The system also stores information in the history file each time a file is added, modified, shared, moved or deleted from a project. This historical record can be output as a report, and an individual can use the report to pinpoint bugs or to manually recreate previous versions of the project. In the context of VISUAL SOURCESAFE, however, there is limited support for projects that span more than one folder. In addition, in an ideal world, the process of recreating previous versions of a project would be automatic, and thus transparent to the individual.
Although prior art systems do provide version control for the actual files of a project, one other feature that is lacking from prior art systems is
Grier Michael J.
Kaler Christopher G.
Kruy Steven J.
Lovell Martyn S.
Microsoft Corporation
Robinson Greta
Woodcock & Washburn LLP
LandOfFree
Project-based configuration management method and apparatus does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Project-based configuration management method and apparatus, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Project-based configuration management method and apparatus will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3190850