CA1316262C - Version management tool - Google Patents
Version management toolInfo
- Publication number
- CA1316262C CA1316262C CA000597671A CA597671A CA1316262C CA 1316262 C CA1316262 C CA 1316262C CA 000597671 A CA000597671 A CA 000597671A CA 597671 A CA597671 A CA 597671A CA 1316262 C CA1316262 C CA 1316262C
- Authority
- CA
- Canada
- Prior art keywords
- version
- line
- path
- file
- record
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000008859 change Effects 0.000 claims description 79
- 238000000034 method Methods 0.000 claims description 58
- 238000011161 development Methods 0.000 claims description 12
- 238000012217 deletion Methods 0.000 claims description 5
- 230000037430 deletion Effects 0.000 claims description 5
- 230000004913 activation Effects 0.000 claims description 4
- 238000001994 activation Methods 0.000 claims 3
- 238000010586 diagram Methods 0.000 description 14
- 238000007726 management method Methods 0.000 description 12
- 239000011159 matrix material Substances 0.000 description 9
- 230000008569 process Effects 0.000 description 6
- 230000000875 corresponding effect Effects 0.000 description 4
- 150000002500 ions Chemical class 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 241000289690 Xenarthra Species 0.000 description 3
- 230000015572 biosynthetic process Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000003455 independent Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000012804 iterative process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99954—Version management
Abstract
IMPROVED VERSION MANAGEMENT TOOL
ABSTRACT OF THE DISCLOSURE
A system for preserving, generating, and merg-ing different versions of a common module that utilizes a line file storing the text of every line in a version and addressing each line with a unique line identifier.
Any desired version may be generated directly without creating intermediate versions. The unique line identi-fiers facilitate a merge operation that does not dupli-cate lines.
ABSTRACT OF THE DISCLOSURE
A system for preserving, generating, and merg-ing different versions of a common module that utilizes a line file storing the text of every line in a version and addressing each line with a unique line identifier.
Any desired version may be generated directly without creating intermediate versions. The unique line identi-fiers facilitate a merge operation that does not dupli-cate lines.
Description
1 3 1 626~
IMPROVED VERSION MANAGEMENT TOOL
BACKGROUND OF THE INVENTION
Field of the Invention The present invention relates generally to the field of software development tools and more particularly relates to a system for maintaining control of various versions of a file and for merging different versions of the same file.
Description of the Relevant Art An important type of software development tool manages multiple versions of a common text file, e.g., a program.
Typically, this function is required in a software development environment where programs are revised frequently, often by different people, and where previous versions must be preserved.
Also, it may be required to merge the changes introduced into independent versions of a common file.
One approach to developing such a management system is described in an article by Tichy entitled "RCS-A System for Version Control", Software-Practice and Experience, John Wiley &
Sons, New York, 1985, pp. 637-654. That article describes common methods for preserving every version of a file and for merging versions of the same file.
Turning first to the method of preserving versions, the delta method is described in the above-referenced article. A
delta is a series of edit commands that change one version into another. A delta ,,, . .
may be a forward delta, for changing a given version into the immediately following version, or a reverse delta, for chanqing a given version into an immediately preceding version.
A reverse delta system is often preferred because experience shows that often the most frequently required version is the last version created. In a reverse delta system, the last version is stored intact and may be immediately accessed. Text files of previous 10 versions must be created by successively applying reverse deltas to the last version created.
A significant limitation in using the delta system to create a text file of a version separated from the last version by several intermediate versions is that each intermediate version must be created and changed by the appropriate delta. This iterative pro-cess limits the speed of accessing intermediate versions.
A given file may develop along a single path where each version evolves from the immediately preced-ing version. Often however, development of a file mayproceed along several independent paths. For example, a first programmer may check out a given file and pro-ceed to create several versions along a first path. A
second programmer may check out the same given file and proceed to create several versions along a second path.
The changes introduced along the first and second paths may be completely independent, e.g., the two program-mers might not talk to each other and have different development goals. The paths are related since they 3C diverge from the same given file.
- In some cases, it may be desirable to merge two versions created along independent paths to form a resulting version incorporating the changes introduced along both paths. ~or example, referring to the exam-ple above, the first programmer may be improving a first aspect of the given program and the second programmer may be improving a second aspect. When they have completed their tasks, a new program improved in both aspects may be created by merging versions from the two paths.
A problem in merging occurs when the same line of the given program is changed in both versions to be merged. It is possible that the changes made will conflict and not be compilable. Accordingly, merge programs have been developed including rules for processing lines changed in both versions.
In many existing systems, the lines included in a given version are identified by line numbers. During a merge, the line numbers in the versions to be merged are compared and lines identified by specified line numbers are included in a resulting version. However, often lines will be duplicated in the resulting version because identical lines will have different line numbers in the versions to be merged.
Accordingly, there is a need for improved software development tools having efficient systems for preserving development versions of a text file, creating desired versions, and merging versions developed along independent paths.
SUMMARY OF THE INVENTION
The present invention is a version management tool having improved systems for preserving all versions, creating any desired version, and merging versions developed from a common file along independent paths.
Broadly, the invention is directed to a method for directly creating a text file of a desired version of a stored text file module, with the desired version comprising a plurality of lines of text. The desired version is included in a t 3 1 626~
3a 64157-280 development path that also includes several other versions. The inventive method generally stores all lines active in the several o~her versions in the development path in an indexed line file, and retrieves only those lines active in the desired version from the line file for inclusion in the text file.
In a preferred embodiment, the fundamental unit for editing is a complete line of text~ Thus, to change a character in a given line of text requires that the given line be deleted and replaced by a new line having the desired character changed.
Every line active (included) in any version of a given file is included in an indexed line file and tagged by a unique line identifier (ULI). The history of the status of .~ ,, - t 31 6262 each line in the various versions is recorded in a var-iant history file.
According to one aspect of the invention, the variant history file i8 an ordered set of records with 5 each record including a ULI, a version number, and a status flag. In one embodiment, if the value of the status flag is (A) then the line identified by the ULI
becomes active in the version identified by the version number included in the record, if the value of the sta-tus flag is (D) then the line identified by the ULI i5deleted in the version identified by the version number included in the record, and, if the value of the status flag is (R) then the line identified by the ULI is re-placed in the version identified by the version number lS in the record.
According to a further aspect of the inven-tion, the text file of a desired version is created by searching the variant history records to identify ULls of llnes active in the desired version. The lines iden-tified are retrieved from the line file and included inthe created text file. The search is facilitated by ordering the records in the variant history file so that a record indicating that a ULI is replaced immedi-ately follows the record indicating that the ULI became active. These records are processed as a pair and the version numbers compared to the version number of the desired version. If the ULI becomes active in a version created before the desired version and is deleted or replaced in a version following the given version then the ULI is act ve in the desired version and the line identified by the ULI i5 included in the text file of the desired version.
In the preferred embodiment, the line file and variant history files of a FROM path and a TO path are utilized to merge a FROM version in the FROM path into a TO version in the TO path to form a resulting version. The result of the merge is that lines are 1 31 626~' either added to or deleted from the new TO version.
Accordingly, the effect of the merge operation is to modify the TO variant history file to create a result-ing variant history for the TO path. This resulting 5 variant history is utilized to create the text file of any desired ver6ion, including the resulting version, in the TO path.
According to a further aspect of the invention, a unique change tag i8 associated with the operation of creating each ver6ion of a module. When a llne is first added to a version, the ULI created for the line includes the change tag associated with the version and a sequence number. A change tag list may be built for any version that includes all change tags which have been applied to create the version.
In an embodiment of the merge operation, the change tag list for the TO and FROM versions are built and a common list of change tags which are included in both lists is built, For lines identified by ULIs hav-ing a change tag in the common list, the status of theline in the resulting version is determined by the sta-tus of the line in the TO and FROM versions and a pre-determined set of rules.
One embodiment includes a computer, operating 25 under control of a ~tored program, for executing the program to perform the procedures described above. The indexed line file and variant history file are built, stored in the computer memory, and utilized to create a text file of a desired version or to merge two versions to form a resulting version.
Other advantages and features of the inven-tion will become apparent in view of the drawings and following detailed description.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. lA is a schematic diagram of a path of development;
t316~62 Fig. lB is a schematic diagram depicting the formation of a second path;
Fig. 2 is a schematic diagram depicting a naming system;
Fig. 3A iB a schematic diagram illustrating the use of an exemplary embodiment of the version man-agement tool loaded into a general purpose digital com-puter;
Fig. 3B is a block diagram of a general pur-10 posed digital computer configured as a version manage-ment tool;
Fig. 4 is a schematic diagram depicting a set of variant history (VH) files and line (LN) files;
Fig. 5 is a schematic diagram depicting the 15 text files corresponding to the variant history files depicted in Fig. 4;
Fig. 6 is a flow chart of a procedure for creating the text file of a desired version;
Fig. 7 is a schematic diagram depicting a 20 merge operation;
Fig. 8 is a diagram of a status matrix;
Fig. 9 is a schematic diagram depicting exem-plary text files, variant history files, and line file for explaining the merge operation;
Figs. lO through 18 are flow charts of the procedures for performing the merge operation; and Fig. 19 is a schematic diagram depicting a complex merge operation.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The present invention includes a unique sys-tem for organizing information regardlng multiple ver-sions of a common text file. This information is orga-nized in a manner that provides for directly creating the text file of any previously created version of the common text file and for efficiently merging the changes t 31 6262 introduced in any two independent paths to create a resulting version incorporating those change~.
GENERAL CONCEPTS AND TERMINOLOGY
The terminology utilized herein will now be defined with reference to Figs. 1 and 2. Referring to Fig. 1, a module i6 the name of a source file lO checked into the system. In thi 6 example the module name is APPLY. A version of the module may be conceptualized 10 in terms of a simple text file. For example, if text file X is in the system, then it can be duplicated to create text file Y which is then modified. Thus Y rep-resents a different version of X. The file Y is then checked back into the system. Versions of files checked into the system are immutable and a request for any file checked into the system retrieves the identical file checked in.
In Fig. lA, a path 12 of development of the module lO is depicted. Each version in the path is identified by a path name ~MAIN) and a version number.
To create version (MAIN.l) the module (MAIN O) is checked out (duplicated) and line aaa is added between line 222 and 333. This modified text file is then checked in as (MAIN.1). A unique change tag (tag), comprising a field of characters, is associated with each operation that creates a new version. Thus, a tag is associated with the operation that creates (MAIN.1).
The versions in a path are identified by version numbers (VN).
Each version in the path 12 is created by modifying the immediately preceding version in the path.
Fig. 1~ depicts two paths of a module formed from the version (MAIN.O). Referring to Fig. lB, the new path 12~b) is formed when a version in a path is checked out, given a new path name, modified, and checked back in. In Fig. lB, the version (MAIN.O) is checked out, given the path name VSER, modified, and checked in.
13162~)~
Thus, the version created from (MAIN.O) is (USE~.O).
Changes sub6equently entered into the two paths will be independent.
The naming scheme utilized will now be de-~cribed with reference to Fig. 2. A variant is a logi-cal name that is used to assoclate one or more versions on a single path of a particular module. This name consists of a module name and a path name. For example, in Fig. lB the two variant names are APPLY:MAIN and 10 APPLY:USER. A version-id includes a path name and ver-6ion number, e.g., (MAIN.1).
ORGANIZATION OF THE SYSTEM
Fig. 3A is a schematic diagram depicting the 15 use of version management procedures 13 loaded into a general purpose digital computer for creating and using a version management system. A user utilizes a user interface to check-in a source file module, check-out desired versions of the module, modify the checked-out 20 version, check-in the checked-out version, name and create new paths of development, and merge modules in independent paths to create a resulting module incorpo-ratinq the changes introduced along the independent paths.
The text files of the various versions are encoded in machine readable form and stored in a struc-tured database 15. The version management procedures 13 build an indexed line file in which the text of every line of every version is 6tored. Each line is identified by a unique line identifier (ULI). The version manage-ment procedures 13 also create a variant history (VH) file in 6tructured database 15 for each path. The var-iant hi6tory file 6tores information relating to the status of the lines in each version along a path.
Additionally, a merge procedure utilizes the indexed line file and variant history files to generate a resulting version incorporating changes introduced along two paths.
~ ig. 3B depicts a standard general purpose diqital computer 17 configured as a version management Rystem. The various version management procedures are stored as program data in the computer memory. The computer memory includes the main memory and peripheral storage devices such as disk drives, tape drives and so forth. During operation, the program data is executed 10 in standard fashion. The various version management procedures are executed to build the structured data-base in the computer memory, to create text files of desired versions, and to merge versions from independent paths.
Fig. 4 is a schematic diagram of a line file (LN) 20 and variant history file (VH) 22 utilized to form different versions of a given module on a given path. A new VH file is created for each independent path of a module. Whenever a new version of a variant is created, a comparison is made between the existing latest version and the text file being checked in. The comparison reports three types of differences, resulting in an updated VH file being written and, possi~ly, ad-ditions being made to the LN file. These three types of differences are:
Deletion: Lines were deleted in the text file. In the new VH file, new records for these ULIs are written, indicating that these lines are "deleted" in this version.
Insertion: New lines were introduced in the text file, directly before a line with ULI
"M" whlch was unchanged. New ULIs are assigned to the new llnes, and new records are introduced in the VH file, directly before the f,rst record for line M. New records containing the text of the new lo t 31 62~
lines are added to the LN file, with the new ULIs as their keys.
Replacement: New lines were introduced in the text file, replacing one or more lines in the version which was checked out. This change is treated as a combination of a deletion and insertion. In the new VH
file, new records for the deleted lines are written, indicating that these lines are ~replaced~ in his version. New ULIs are assigned to the new lines, and new rec~rds are introduced in the VH
file, directly after the records for the replaced lines. New rec~r~ds containing the text of the neh7 lines a~-e added to the LN file, wi~h the new ULls as their keys.
. In the present embodiment, the smallest unit of c~ange within a module is a line. Thus, if a char-acter in a line i8 modified this modification is accom-plished by deleting the unmodified line and replacing it with a new line.
Referring now to Ei~. g~ the LN 20 is an in-dexed file that includes the lines active in all versions in all paths of develop~ent of a module. Each line is identified by a uniqu~ line identifier ~ULI) 24 consist-ing of two parts; a change tag 26 (which identifies when the line was added to the module) and a sequence number 28 (which identifies the line within a tag s changes). The ULI functions afi an address for the lines in the LN 20 and is utilized to access the lines to create a text file of a selected verslon.
The variant history file 22 comprises an or-dered li~t of records 30. These records 30 indicate changes of status of the lines, identified by the ULIs in the records, in the various versions along the given path. The change of status of a given line is indicated 1 ~1 62~$2 by the values of a status flag (A for active), (R for replaced), and (D for deleted) ~nd a ver~ion number (VN) of a version in the given path. For example, if a line identified by ULI(l) i~ added in version 3, then 5 the VH record includes ULI(1), the value of the status flag i8 (A), and VN=3. The VH file may include several records for a given ULI if the line identified undergoes several status changes. The records in the VH file are ordered to facilitate the direct creation of a text file for any version in the path.
Referring back to Fig. lB, a version (USER.-l) created in the USER path i8 a copy of (MAIN.0). The VH
file of the MAIN PATH (MVH) is copied to form the VH
file of the USER path (UVH). The UVH is then updated to reflect the change made to (MAIN.0), or equivalently (USER.-l), to form (USER.0).
The creation of (USER.-l) is necessary to create a VH file for the USER path and illustrates the fact that the paths diverge from the module (MAIN.0).
The path of development of both paths up to and includ-ing version (MAIN.0)/(USER.-l) is identical. To reflect this identity, the W H file is built by creating a set of records corresponding to the records in the MVH
file. The ULI and status flag in corresponding records are identical. However, the VNs in the W H records are set to -1.
The creation of (USER.-l) is transparent.
The first version in the USE~ path subject to normal proce~sing is (USER.0), where the line uuu is added to the text file of (MAIN.0).
It i8 possible to reactivate a deleted or replaced line using a backout operation. Thls operation removes changes associated with A particular version of a module. For example, a line identified by a given ULI might be deleted to create the particular module.
If this change were ~ubseguently backed out, then the line would become active again. This activation would ~ 31 6.~62 be reflected in a VH record including the given ULI, the VN of the version created by the backout operation, and the status flag (A).
Fig. 5 depicts three versions 40 of a module 5 formed on a first path. The LN 20 and VH files 22 corre-sponding to these versions are depicted in Fig. 4. The formation of the LN 20 and VH 22 for the first path will now be described.
The LN 20a for the first version 40a includes 1~ all the lines of the first version 40a with each line identified by a ULI 24. The field E in the ULIs is the change tag associated with the operation of creating the first version.
In the second version 40b, the first line of the first ~ersion 40a has been replaced by a new line.
Referring to the second LN 20b, the new line has been added to the LN 20b and is identified by a ULI where the field S1 is the change tag associated with the opera-tion of creating the second version 40b. The LN 20b 20 has been updated to include the lines added in the opera-tion of creating the second version 40b. Note that no lines are ever deleted from the LN 20b.
Referring now to the VH files, the first VH
file 22a includes four records 30, each including one of the ULIs of the lines in the first version and spec-ifying that the lines become active in version 0. The 6econd VH file 22b, includes all the records from the first VH file 22a and additional records indicating the changes entered into the second version 40b. More spe-cifically, the records are sequentially numbered toclarify the following description. The second record h~s been added to indicate that line E.1 has been re-placed in the second version. Note that the records with the same ULI are adjacent. The third record iden-tifies the line that has replaced the deleted line.This record immediately follows the last record indicat-ing a replaced line.
1 31 6~6~
Again, as with the LN 20, the second VH file 22b is formed by updating the first VH file 22a and no records have been deleted.
Referring again to Fig. 5, the third version 5 40c is updated by replacing the first two lines of the second version 40b with new lines. The new LN 20c iB
formed by adding the lines identified by ULIs S2.1 and S2.2 to the second LN 20b. The field S2 in the ULIs is the change tag associated with the operation of creating 10 the third version.
Turning to the third VH file 22c, those records having VNs equal to 0 or 1 are the records from the 6econd VH file 22b. The fourth record indicates that the line identified by S1.1 is replaced in the third 15 version; the sixth record indicates that the line iden-tified by E.2 is replaced in the third version; and, the seventh and eighth records indicate that the lines identified by S2.1 and S2.2 are added in the third ver-sion. The records indicating lines added in the third version immediately follow the last record indicating that a line has been replaced.
At this point, all the information required to create the text file of any version in the path is included in the LN 20c and the VH 22c. Further, the text file of a selected version is created directly without the requirement of creating intermediate ver-~ions.
PROCEDURE FOR CREATING A TEXT FILE
Fig. 6 ls a flow chart illustrating the pro-cedure for creating a selected version, VN=M, in a path.
Referring to Fig. 6, the flrst VH record is read 50 and saved 52. An attempt is then made to read 54 the next VH record. If there are no more records then the end of the file has been reached 56 and the process branches to a closing label (B) 57. Otherwise, the ULI 5 of the saved and read records are then compared 58 to determine whether they are different.
If they are not different then, because of the ordering of the records in the VH file, the second record indi-cates the version number where the identified line is replaced or deleted. Accordingly, the version number of the red record is compared 60 to M to determine whether the identified line was deleted in a version following the version being created. If this version number is greater than M, then the line was deleted in a preceding version or the desired version and is not included in the version M. Accordingly, the process branches back to point A.
If this version number is greater than M, then the line is deleted in a subsequent version in the path. Thus, the value of the status flag is examined 62 and the version number of the saved record is com-pared 64 to M. If the version number in the saved record is less than or equal to M and the value of the status flag is (A) then the identified line becomes active in a preceding or the desired version, is retrieved from the line file, and is included in the text file of the version M. If the version number is greater than M
then this ULI does not affect version M and the process branches back to point A.
Returning to step 58, if the ULIs are differ-ent then the value of the status flag in the saved record is examined 62 and the VN is compared 64 to M. The line identified by the ULI in the saved record is in-cluded 66 in the text file if the value of the status flag in the saved record is (A) and the VN is less than or equal to M. If the version number in the saved record is greater than M, then the identified line was intro-duced in a version following version M and is not present in version M. In this case, the process branches to point A.
Each adjacent pair of records in the VH is processed, with the first record in the pair being the ~ 31 6262 saved record and the second record in the pair being the next read record, as described above until the end of the VH file is reached.
The closing subroutine 57 wlll now be described.
5 The last record is examined to determine if status flag is (A) 57b, and if the VN is less than or equal to M
57c. If both these conditions are met than the llne ldentified by the ULI in the last record is included 57d in version M. Otherwise, the line is not included and the process returns 57e to a calling program.
A specific example of the operation of this process to create ver6ion 1 of Fig. 5 utilizing the VH
and line file 20(c) and 22(c) of Fig. 4 will now be described for the case M=1. Referring now to Figs.
4-6, the ULIs of the first pair of records, the first and second, are not different 58 and the VN of the sec-ond record is not greater than 1 60. Thus, the line identified by the ULI is replaced in version 1 and is not included.
The ULIs of the next pair of records, the second and third, are different 58, the VN in the sec-ond record is equal to M 64, but the status flag is not (A) 62. Thus, the line identified by the ULI is not included.
The ULIs in the next pair of records, the third and fourth, are not different 58, the VN in the fourth record is greater than M 60, the value of the status flag in the third record is (A) 62, and the VN
of the first record is equal to M 64. Accordingly, the line identified by the first record, stu, is included 66 in the text file of version 1. The proces6 for cre-ating the remainder of the text flle for version 1 fol-lows directly from the above description.
It is now apparent that the procedure depict-ed in Fig. 4 i~ able to utilize the VH and LN files fora given path and directly create the text file of a selected version in the path.
1 31 ~o2 DESCRIPTION OF THE MERGE PROCEDURE
An important feature of the present system is the ability to merge changes introduced along two inde-pendent paths into a resulting version. This procedure 5 is illustrated in Fig. 7. The letters ln parentheses are the change tags assoclated wlth the operation of creating each version. These change tags appear in the ULIs of all new lines added in the associated versions.
Versions (T.O), (T.l), and (T.2) form the first three versions ln a TO path 70. The first version (F.O) in a FROM path 72 and version (T.3) in the TO
path both diverge from (T.2). Each path has its own VH
file and shares a single common LN file.
The operation of merging version (F.2), the FROM version, into version (T.4), the TO version, creates a resulting version (T.5) reflecting the changes made along both paths subsequent to their divergence at ver-sion.(T.2). Accordingly, a resulting VH file (RVH) must be created so text files of all versions in the TO
20 path, including the resulting version (T.5), may be created from the RVH file utilizing the procedure de-ficribed with reference to Fig. 6.
The change licts for (F.2) and (T.4) are re-guired to perform the merge operation. A change list is a list of the change tags which have been applied to create the version owning the list. Table 1 depicts the change lists for versions (F.2) and (T.4).
VERSION CHANGE LIST
(F.2) A,B,C,S,T,U
(T.4) A,B,C,DE
The procedure for creating the ~VH file in-cludes the steps of generating a common list (tags in both change lists), a TO list (change list for the TO
17t~6262 version), and a FROM list (change list for the FROM
version). Table 2 depicts the change tags in these lists.
COMMON LIST A,B,C
FROM LIST A,B,C,S,T,U
TO LIST A,B,~,D,E
The status of a given line in the resulting version depends on the change tag included in the ULI
identifying the given line. If the change tag is in the common list, then the status of the given line in the resulting version depends on the status of the given line in both (F.2) and (T.4) and iR determined by a set of predetermined rules.
The predetermined set of rules utilized to determine the status of the given 11ne identified by a ULI having a change tag in the common list is represented in Fig. 8 by a matrix 83. Referring to Fig. 8, the matrix 83 has its rows labelled by the status of the given line in the FROM path and its columns labelled by the status of the given line in the TO path. The ele-25 ments in the matrix 83 are set forth in boxes 84 seguen-tially numbered from O to 35. The meaning of the symbols utilized to label the rows and columns of the matrix are defined in Table 3. The symbols utilized to define the matrix elements 86 are defined in Table 4. An (*) in a box 84 indicates that a new record will be written to the RVH file. The method for utilizing the matrix will be described more fully below.
SActive,c=): line was active when files diverged/prev-iously merged and has not been altered since then;
18 ~316262 (Active,>): a backout of a change, resulted in a change to this ULI since the files diverged/previously merged;
(Inactive delete,<=): line was deleted when files di-5 verged/previously merged and ha~ not been altered since then;
(Inactive delete,>): line was deleted since the files diverged/previously merged;
(Inactive replace,<=): line was replaced when files diverged/previously merged and has not been altered since then;
(Inactive replace,>): line was replaced since the files diverged/previously merged.
A: the result of the merge is that the ULI is left active; no new VH record is written;
I: the result of the merge is that the ULI is left inactive; no new VH record is written;
R: the result of the merge is that the ULI i9 left replaced; no new VH record is written;
A*: create a new VH record indicating that the ULI is now active;
I*: create a new VH record indicating that the ULI is now deleted;
R*: create a new VH record indicat~ng that the ULI is now replaced.
The symbol6 ~= and > indicate the result of a comparison between the change which created the VH record being considered and the common list of changes. This determines whether the VH record' B information was already 5 known when the paths diverged or were la~t merged, or whether the information ls new since the last such point of divergence.
The mechanism currently used for deciding when a change occurred ln relation to the last divergence 10 point involves comparing the version number in a VH
record with a "common version" on the path currently being considered.
The "common version" i6 determined by compar-ing the common list of tags with the list of tags present in each significant version of the TO or FROM path, starting at the earliest version. The first such version which includes all common tags, or includes tags not found in the common list, i8 the desired common ver~ion.
Thus for a simple case, where version O of a new path is being merged back into the path from which it diverged, the common version would be -1.
The procedure for merging two modules will now be described with reference to Figs. 9 through 18.
Fig. 9 illustrates a merge operation from version (F.O) (FROM version) in a FROM path to version (M.l) (TO ver-sion) in a MAIN path. The text file and ULIs for each version are depicted. Additionally, the VH file gener-ated when each version was created iB shown associated with the various versions. The change lists for (F.O) and (M.1) are depicted in Table 5 and the common, TO, and FROM lists are depicted in Table 6.
VERSION CHANGE LIST
(F.0) E,F0 (M.l) E,Ml l 3l 62 62 COMMON LIST E
FROM LIST E,FO
TO LIST E,M1 The VH flle associated with (F.O) i8 the FVH, the VH file associated with (M.l) is the TVH, and the VH file associated with (M.2) is the RVH.
Fig. 10 i8 a flow chart listlng the steps in the Merge-Main routine which coordinates the overall merge operation. This program invokes numerous subrou-tines which perform the detailed operations necessary to merge two paths of a module.
Referring now to Fig. 10, the first step lOO
is to build a list of the module names to lnclude and exclude from the merge. In the present example, module E is included in the merge. Next, the merge list is tested 102 to determine whether there are more modules to merge. If no, then the program branches to a closing label A 103. If yes, the LN file for module E, and VH
files for the FROM and TO variants are opened 104 and a new VH file (RVH) is created 106 for the results of the merge.
Next, the procedure for merging the variant paths is called 108. These procedures are described below. If the merge is successful 110 then the variant record is updated 112, lf not the program jumps to step 102. Next, a new record describing the version is cre-ated 114 and and the LN file and VH files are closed 116. The program then returns to step 102. If there are no more modules to be merged, then the closlng por-tion 103 is executed.
Referring to the closing, a change record is built 103a to reflect the merge, the new VH file is renamed and the old one purged 103b, and the results of the merges are reported 103c.
21 t3l626~-) Fig. 11 is a flow chart listing the steps of the MERGE-VARIAMT-PATHS procedure. This procedure con-trols the mechanics of merging two paths of one module.
Referring to Fig. 11, the TO list, FROM list, and common list for (F.0) and (M.l) are generated 310. The contents of these lists are set forth above ln Tables 5 and 6.
Next, the lists are examined 320 to determine whether the FROM list i8 a subset of the TO list. If yes, than there i 6 no need to proceed further because the 6tatus of all lines in the FROM version have already been used in determining the status of the lines in the TO version.
If not, then the first record from the TVH
and FVH files are read 340. Next, it is determined that the end of the file has not been reached 350. The pro-cedure then tests the change tags in the ULIs of theread records to determine whether the tags in the VLIs in the first TVH and FVH records are in the common list 360, whether only the tag in the firqt TVH record is in the common li~t 362, whether only the tag from the first ~0 FVH record is in the common list 364, or whether neither the tag in the first FVH record nor the the tag in the first TVH record is in the common list. Depending on which condition is true, the appropriate subroutine 368, 370, 372, or 374 is called.
The operation of the MERGE-VARIANT-PATHS sub-routine 300 will be described with reference to the example illustrated in Fig. 9. The first record in the TVH file (E.0 0 A) and in the FVH file (E.0 -l A) are read 340. The change tag (E) in both records are in the common list 360 and the subroutine PROCESS-ULI-IN-BOTH-PATHS ~s called 368.
Fig. 13 is a flow chart of this subroutine.
Referrin~ to Fig. 13, the ULI 6 in both records match 502. The read (first) TVH record is written to the new VH file 504 and the value of the status flag (A) of the record is saved 506. The next (second) TVH record (E.1 0 A) is read 508 and the saved ULI and ULI of the next 1 31 6~k?
read record are compared 510. In thls case, the ULIs are different.
The read (first) FVH record is then examined to determine whether the version number in the record 5 i8 less than or equal to the vers~on number of (F.0) 512, and iE BO, the ~tatus flag of the record i6 6aved 513. In this case, the version number (-l) in the record i6 less than the version number (O) of the FROM version and the 6tatus flag (A) i8 saved. The next (second) 10 FVH record (E.l -l A) is read 514 and the ULIs of the saved and next read FROM records are compared 516.
In this case, the ULIs are different and the ~aved status flags are utilized 518 to execute the case statement which implements the predetermined set of rules. As described above, this set of rules is shown as a matrix. Referring to Fig. 8, and Tables 5 and 6, for both paths the line was active before divergence and no changes have been made since then (A,<=). Ac-cordingly, case statement 0 is executed and the line is active in the resulti~g version. The result of the subroutine is that the first record in the RVH file is the same as the first record in TVH file and no new - record is created. The subroutine then returns 520 to the calling subroutine.
The steps 350, 360, and 368 of the MERGE-VARIANT-PATHS procedure are then repeated for the sec-ond records in TVH and FVH files and the subroutine PROCESS-ULIS-IN-BOTH-PATHS 368 is called. From the structure of the TVH and FVH files it is apparent that the first five records in those files are processed as described above and that the first five records in the RVH file are the same as the flrst flve records ln the TVH file.
Referring to Fig. 13, after the fifth TVH
record is written 504 and the sixth TVH record is read ~08, the ULIs of the two records are compared 510. In this case the ULIs are not different and the subroutine 23 1 31 626~
branches back to step 504. The sixth TVH record (E.4 1 R) iB written to the RVH file, the status flag (R) is 6aved 506, and the seventh TVH record (FO.O O A) i6 read 50~. The ULIs are then compared 510 and found 5 to ~e different.
The sixth FVH record (E.4 0 R) ls read 514 and its ULI is compared to the ULI of the fifth record 516. The ULI 5 are the same so the subroutine branches back to 6tep 512. The status flag (R) of the sixth record iB saved 513 and the seventh FVH (FO.O O A) record is read 516. The ULIs of the sixth and 6eventh records are compared 516 and found to be different.
The saved status flags are then utilized 518 to execute on of the case statements of the predetermined 6et of rules. As described above, this set of rules is implemented as a case statement based on the matrix shown in Fig. 8. Referring to Fig. 8, and Tables 5 and 6, for both paths the line was replaced since diver-gence (R,~). Accordingly, case statement 35 iB executed, the line is replaced in the resultlng version, a new record is generated and written to the ~VH file, and a conflict message is generated. The result of the execut-ing the subroutine iB that the record (E.4 2 R) is generated and written as the seventh RVH record. The subroutine then returns 520 to the calling subroutine.
The change tags of the ULI B in the seventh TV~ and FVH records are compared to the change tags in the common list and it iB determined that neither tag is ln the common list 360,362,364. Accordingly, the subroutine NEW-LINES-IN-BOTH-PATHS 18 called 374.
Fig. 17 iB a flow chart for this subroutine.
In Fig. 17, first the TVH file records are processed 900 and then the FVH file records are processed 910.
If it iB determined that llnes from both paths are ac-tive in the resulting version 920, then a warning mes-sage is printed and the active lines are displayed 922.
This feature calls attention to the possible conflict between the lines added along the independent paths and provides for a ~ulck review of the lines added. The method of ~eeping track of these active lines is described below.
The subroutine PROCESS-ULI-IN-TO-PATH i B called in step 900. Fig. 14 is a flow chart for this ~ubroutine.
In Fig. 14, the seventh TVH record is written to the new VH 600, the eighth TVH record i8 read 602, and the ULIs of the two records are compared 60~. In this case 10 the ULIs are different, the status flag in the ~eventh record is examined 608 to determine whether the value of the status flag is (A), and active-TO-ULI-count is incremented 608. This count keeps track of new ULIs added in the TO path ~ince the point of divergence and which are active. The change tag of the ULI in the eighth record is then compared to the change tags in the common list 610 to determine whether the ULI is in the common list. In this case it iB not and the sub-routine branches back to step 600.
The processing of the eighth through eleventh TVH records is the same as described above with the result that these records become the ninth through twelfth records of the RVH. The twelfth TVH record (E.5 0 A) is read 602, the count is incremented 609, it is deter-25 mined that the new ULI read is in the common list 610, and the subroutine returns to step 900 of the calling subroutine. The subroutine PROCESS-ULI-IN-FROM-PATH is then called 910.
Eig. 16 i8 a flow chart of that subroutine.
In Fig. 1~, the ~tatus flag (A) of the seventh FVH record i6 ~aved 800 because the version number in the record is equal to version number of the FROM version, the eighth FVH record is read B10, ~nd ULIs of the records are compared 812. In this case, the ULIs are different and a new VH record is built 814 that reflects the last saved state. This new VH record, (FO.O 2 A), indicates that the line identified by the ULI (FO.O) becomes active l 3t 6262 in version 2, the resulting version, in the T0 path as a result of the merge operation and which are active.
The record built is written to the RV~ file 816 a~d the ~tatus flag of the record i8 examined 818 to determine 5 whether its value is (A). If BO, nctive-FROM-ULI-count i6 incremented 820. This count keeps track of new lines added from the FROM path during the merge operation and which are active. The change tag of the ULI in the eighth record iB then compared 822 to the change tags 10 in the common list to determine whether the ULI i~ in the common list. In this ca6e it i8 not and the sub-routine branches back to step 800.
The processing of the eighth through tenth FVH records is the same as de~cribed above with the result that the fourteenth through 6ixteenth records are built reflecting that these lines become active as a result of the merge.
It is determined 822 th~t the change tag in the ULI of the eleventh FVH record is in the common list and the subroutine returns 824 to step 910 of the calling ~ubroutine. The counts generated in the two called subroutines indicate that new lines in both paths become active in the resulting version and the warning message is printed and the new lines are displayed 922.
The subroutine then returns to step 350 of the calling procedure.
It is then determined that the change tags of the eleventh FVH record and twelfth TVH record are in the common list 360, and the procedure PROCESS-ULI-IN-BOTH-PATHS described above are utilized to write the twelfth through fifteenth TVH records to the new VH.
It 1~ then determined that the end of a VH file is reached and part (B), Fig. 12, ls executed to complete the merge.
Fig. 18 depicts the subroutine SKIP-THIS-MERGE-ULI. This subroutine is not used in the above example but may be called by the 6ubroutine PROCESS-FROM-PATH-26 l 31 6267 VH-RECS when the FROM version is not the last version created in the FROM path. Thi 6 6ubroutine prevents changes made in the FROM path subsequent to the creation of the F~OM version from being included in the resulting 5 version.
The generation of change lists and determina-tion of the point of divergence for the example of Fig. 9 was possible from inspection. However for more complicated cases where several independent paths exi Bt and merges between paths have been made prevlously, the generation of the list is more difficult. Fig. 20 is a schematic diagram depicting such a complex case. The se of the change list to generate the common list is important to the above-described merge procedure and facilitates the generation of conflict messages and other advantageous features.
A generalized procedure for building the change list for a version will now be described. This procedure i8 an application of graph theory. A signiflcant version 20 i8 defined as either the first ver~ion in a variant (i.e. version 0), or was the version from which a new variant was created, or was the version created as the result of a merge operation, or was the version from which a merge was done. All slgnificant versions are candidates for being the common verQions in a merge operation.
The versions of the module are considered as part of a directed, acyclic graph. All versions of the module are descendents of the original version (version O) in the original path. Each version can be created in only one of four ways, i.e., a) by adding a module to the database; b) by checking ln a checked out ver-sion; c) by creating a new path; or, d) as the result of a merge operation.
The algorithm for creating the change tags starts by representing the graph of versions as a graph of significant versions. Each such version is assigned 1 31 626?
its own change list, which is initially empty. The first (earliest) significant node has its own change tag placed in its change list, Next, the call VISIT(ear-liest node~ is made, where VISIT is the following recur-5 sive procedure:
procedure VISIT(j) { j i8 a node in the graph}
begin for each node k, where the link (j->k) exists, do begin if (k is the result of a merge) and (change tag for node j is not in list(k))then list(k) ~- COMBINE(j,k) else list(k) ~- COMBINElj,k) call VISIT(k) end end.
Where the procedure COMBINE is:
procedure COMBINE(x,y) {x and y are nodes, and this procedure returns a change list begin make resulting list empty add every change tag in list(x) to resulting list add every change tag ln list(y) to resultlng li~t add change tag for node x to resulting list return resulting list end.
1 3t 626~
The invention has now been described in terms of preferred embodiments. Modifications and substitu-tions will now be apparent to persons of ordinary skill ln the art. In particular, the rules for processing 5 ULIs in both the TO and FROM paths may be varied accord-ing to specific systems _equirements. Therefore, it is not intended that the ~nvention be limited except as provided by the appended claims.
IMPROVED VERSION MANAGEMENT TOOL
BACKGROUND OF THE INVENTION
Field of the Invention The present invention relates generally to the field of software development tools and more particularly relates to a system for maintaining control of various versions of a file and for merging different versions of the same file.
Description of the Relevant Art An important type of software development tool manages multiple versions of a common text file, e.g., a program.
Typically, this function is required in a software development environment where programs are revised frequently, often by different people, and where previous versions must be preserved.
Also, it may be required to merge the changes introduced into independent versions of a common file.
One approach to developing such a management system is described in an article by Tichy entitled "RCS-A System for Version Control", Software-Practice and Experience, John Wiley &
Sons, New York, 1985, pp. 637-654. That article describes common methods for preserving every version of a file and for merging versions of the same file.
Turning first to the method of preserving versions, the delta method is described in the above-referenced article. A
delta is a series of edit commands that change one version into another. A delta ,,, . .
may be a forward delta, for changing a given version into the immediately following version, or a reverse delta, for chanqing a given version into an immediately preceding version.
A reverse delta system is often preferred because experience shows that often the most frequently required version is the last version created. In a reverse delta system, the last version is stored intact and may be immediately accessed. Text files of previous 10 versions must be created by successively applying reverse deltas to the last version created.
A significant limitation in using the delta system to create a text file of a version separated from the last version by several intermediate versions is that each intermediate version must be created and changed by the appropriate delta. This iterative pro-cess limits the speed of accessing intermediate versions.
A given file may develop along a single path where each version evolves from the immediately preced-ing version. Often however, development of a file mayproceed along several independent paths. For example, a first programmer may check out a given file and pro-ceed to create several versions along a first path. A
second programmer may check out the same given file and proceed to create several versions along a second path.
The changes introduced along the first and second paths may be completely independent, e.g., the two program-mers might not talk to each other and have different development goals. The paths are related since they 3C diverge from the same given file.
- In some cases, it may be desirable to merge two versions created along independent paths to form a resulting version incorporating the changes introduced along both paths. ~or example, referring to the exam-ple above, the first programmer may be improving a first aspect of the given program and the second programmer may be improving a second aspect. When they have completed their tasks, a new program improved in both aspects may be created by merging versions from the two paths.
A problem in merging occurs when the same line of the given program is changed in both versions to be merged. It is possible that the changes made will conflict and not be compilable. Accordingly, merge programs have been developed including rules for processing lines changed in both versions.
In many existing systems, the lines included in a given version are identified by line numbers. During a merge, the line numbers in the versions to be merged are compared and lines identified by specified line numbers are included in a resulting version. However, often lines will be duplicated in the resulting version because identical lines will have different line numbers in the versions to be merged.
Accordingly, there is a need for improved software development tools having efficient systems for preserving development versions of a text file, creating desired versions, and merging versions developed along independent paths.
SUMMARY OF THE INVENTION
The present invention is a version management tool having improved systems for preserving all versions, creating any desired version, and merging versions developed from a common file along independent paths.
Broadly, the invention is directed to a method for directly creating a text file of a desired version of a stored text file module, with the desired version comprising a plurality of lines of text. The desired version is included in a t 3 1 626~
3a 64157-280 development path that also includes several other versions. The inventive method generally stores all lines active in the several o~her versions in the development path in an indexed line file, and retrieves only those lines active in the desired version from the line file for inclusion in the text file.
In a preferred embodiment, the fundamental unit for editing is a complete line of text~ Thus, to change a character in a given line of text requires that the given line be deleted and replaced by a new line having the desired character changed.
Every line active (included) in any version of a given file is included in an indexed line file and tagged by a unique line identifier (ULI). The history of the status of .~ ,, - t 31 6262 each line in the various versions is recorded in a var-iant history file.
According to one aspect of the invention, the variant history file i8 an ordered set of records with 5 each record including a ULI, a version number, and a status flag. In one embodiment, if the value of the status flag is (A) then the line identified by the ULI
becomes active in the version identified by the version number included in the record, if the value of the sta-tus flag is (D) then the line identified by the ULI i5deleted in the version identified by the version number included in the record, and, if the value of the status flag is (R) then the line identified by the ULI is re-placed in the version identified by the version number lS in the record.
According to a further aspect of the inven-tion, the text file of a desired version is created by searching the variant history records to identify ULls of llnes active in the desired version. The lines iden-tified are retrieved from the line file and included inthe created text file. The search is facilitated by ordering the records in the variant history file so that a record indicating that a ULI is replaced immedi-ately follows the record indicating that the ULI became active. These records are processed as a pair and the version numbers compared to the version number of the desired version. If the ULI becomes active in a version created before the desired version and is deleted or replaced in a version following the given version then the ULI is act ve in the desired version and the line identified by the ULI i5 included in the text file of the desired version.
In the preferred embodiment, the line file and variant history files of a FROM path and a TO path are utilized to merge a FROM version in the FROM path into a TO version in the TO path to form a resulting version. The result of the merge is that lines are 1 31 626~' either added to or deleted from the new TO version.
Accordingly, the effect of the merge operation is to modify the TO variant history file to create a result-ing variant history for the TO path. This resulting 5 variant history is utilized to create the text file of any desired ver6ion, including the resulting version, in the TO path.
According to a further aspect of the invention, a unique change tag i8 associated with the operation of creating each ver6ion of a module. When a llne is first added to a version, the ULI created for the line includes the change tag associated with the version and a sequence number. A change tag list may be built for any version that includes all change tags which have been applied to create the version.
In an embodiment of the merge operation, the change tag list for the TO and FROM versions are built and a common list of change tags which are included in both lists is built, For lines identified by ULIs hav-ing a change tag in the common list, the status of theline in the resulting version is determined by the sta-tus of the line in the TO and FROM versions and a pre-determined set of rules.
One embodiment includes a computer, operating 25 under control of a ~tored program, for executing the program to perform the procedures described above. The indexed line file and variant history file are built, stored in the computer memory, and utilized to create a text file of a desired version or to merge two versions to form a resulting version.
Other advantages and features of the inven-tion will become apparent in view of the drawings and following detailed description.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. lA is a schematic diagram of a path of development;
t316~62 Fig. lB is a schematic diagram depicting the formation of a second path;
Fig. 2 is a schematic diagram depicting a naming system;
Fig. 3A iB a schematic diagram illustrating the use of an exemplary embodiment of the version man-agement tool loaded into a general purpose digital com-puter;
Fig. 3B is a block diagram of a general pur-10 posed digital computer configured as a version manage-ment tool;
Fig. 4 is a schematic diagram depicting a set of variant history (VH) files and line (LN) files;
Fig. 5 is a schematic diagram depicting the 15 text files corresponding to the variant history files depicted in Fig. 4;
Fig. 6 is a flow chart of a procedure for creating the text file of a desired version;
Fig. 7 is a schematic diagram depicting a 20 merge operation;
Fig. 8 is a diagram of a status matrix;
Fig. 9 is a schematic diagram depicting exem-plary text files, variant history files, and line file for explaining the merge operation;
Figs. lO through 18 are flow charts of the procedures for performing the merge operation; and Fig. 19 is a schematic diagram depicting a complex merge operation.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The present invention includes a unique sys-tem for organizing information regardlng multiple ver-sions of a common text file. This information is orga-nized in a manner that provides for directly creating the text file of any previously created version of the common text file and for efficiently merging the changes t 31 6262 introduced in any two independent paths to create a resulting version incorporating those change~.
GENERAL CONCEPTS AND TERMINOLOGY
The terminology utilized herein will now be defined with reference to Figs. 1 and 2. Referring to Fig. 1, a module i6 the name of a source file lO checked into the system. In thi 6 example the module name is APPLY. A version of the module may be conceptualized 10 in terms of a simple text file. For example, if text file X is in the system, then it can be duplicated to create text file Y which is then modified. Thus Y rep-resents a different version of X. The file Y is then checked back into the system. Versions of files checked into the system are immutable and a request for any file checked into the system retrieves the identical file checked in.
In Fig. lA, a path 12 of development of the module lO is depicted. Each version in the path is identified by a path name ~MAIN) and a version number.
To create version (MAIN.l) the module (MAIN O) is checked out (duplicated) and line aaa is added between line 222 and 333. This modified text file is then checked in as (MAIN.1). A unique change tag (tag), comprising a field of characters, is associated with each operation that creates a new version. Thus, a tag is associated with the operation that creates (MAIN.1).
The versions in a path are identified by version numbers (VN).
Each version in the path 12 is created by modifying the immediately preceding version in the path.
Fig. 1~ depicts two paths of a module formed from the version (MAIN.O). Referring to Fig. lB, the new path 12~b) is formed when a version in a path is checked out, given a new path name, modified, and checked back in. In Fig. lB, the version (MAIN.O) is checked out, given the path name VSER, modified, and checked in.
13162~)~
Thus, the version created from (MAIN.O) is (USE~.O).
Changes sub6equently entered into the two paths will be independent.
The naming scheme utilized will now be de-~cribed with reference to Fig. 2. A variant is a logi-cal name that is used to assoclate one or more versions on a single path of a particular module. This name consists of a module name and a path name. For example, in Fig. lB the two variant names are APPLY:MAIN and 10 APPLY:USER. A version-id includes a path name and ver-6ion number, e.g., (MAIN.1).
ORGANIZATION OF THE SYSTEM
Fig. 3A is a schematic diagram depicting the 15 use of version management procedures 13 loaded into a general purpose digital computer for creating and using a version management system. A user utilizes a user interface to check-in a source file module, check-out desired versions of the module, modify the checked-out 20 version, check-in the checked-out version, name and create new paths of development, and merge modules in independent paths to create a resulting module incorpo-ratinq the changes introduced along the independent paths.
The text files of the various versions are encoded in machine readable form and stored in a struc-tured database 15. The version management procedures 13 build an indexed line file in which the text of every line of every version is 6tored. Each line is identified by a unique line identifier (ULI). The version manage-ment procedures 13 also create a variant history (VH) file in 6tructured database 15 for each path. The var-iant hi6tory file 6tores information relating to the status of the lines in each version along a path.
Additionally, a merge procedure utilizes the indexed line file and variant history files to generate a resulting version incorporating changes introduced along two paths.
~ ig. 3B depicts a standard general purpose diqital computer 17 configured as a version management Rystem. The various version management procedures are stored as program data in the computer memory. The computer memory includes the main memory and peripheral storage devices such as disk drives, tape drives and so forth. During operation, the program data is executed 10 in standard fashion. The various version management procedures are executed to build the structured data-base in the computer memory, to create text files of desired versions, and to merge versions from independent paths.
Fig. 4 is a schematic diagram of a line file (LN) 20 and variant history file (VH) 22 utilized to form different versions of a given module on a given path. A new VH file is created for each independent path of a module. Whenever a new version of a variant is created, a comparison is made between the existing latest version and the text file being checked in. The comparison reports three types of differences, resulting in an updated VH file being written and, possi~ly, ad-ditions being made to the LN file. These three types of differences are:
Deletion: Lines were deleted in the text file. In the new VH file, new records for these ULIs are written, indicating that these lines are "deleted" in this version.
Insertion: New lines were introduced in the text file, directly before a line with ULI
"M" whlch was unchanged. New ULIs are assigned to the new llnes, and new records are introduced in the VH file, directly before the f,rst record for line M. New records containing the text of the new lo t 31 62~
lines are added to the LN file, with the new ULIs as their keys.
Replacement: New lines were introduced in the text file, replacing one or more lines in the version which was checked out. This change is treated as a combination of a deletion and insertion. In the new VH
file, new records for the deleted lines are written, indicating that these lines are ~replaced~ in his version. New ULIs are assigned to the new lines, and new rec~rds are introduced in the VH
file, directly after the records for the replaced lines. New rec~r~ds containing the text of the neh7 lines a~-e added to the LN file, wi~h the new ULls as their keys.
. In the present embodiment, the smallest unit of c~ange within a module is a line. Thus, if a char-acter in a line i8 modified this modification is accom-plished by deleting the unmodified line and replacing it with a new line.
Referring now to Ei~. g~ the LN 20 is an in-dexed file that includes the lines active in all versions in all paths of develop~ent of a module. Each line is identified by a uniqu~ line identifier ~ULI) 24 consist-ing of two parts; a change tag 26 (which identifies when the line was added to the module) and a sequence number 28 (which identifies the line within a tag s changes). The ULI functions afi an address for the lines in the LN 20 and is utilized to access the lines to create a text file of a selected verslon.
The variant history file 22 comprises an or-dered li~t of records 30. These records 30 indicate changes of status of the lines, identified by the ULIs in the records, in the various versions along the given path. The change of status of a given line is indicated 1 ~1 62~$2 by the values of a status flag (A for active), (R for replaced), and (D for deleted) ~nd a ver~ion number (VN) of a version in the given path. For example, if a line identified by ULI(l) i~ added in version 3, then 5 the VH record includes ULI(1), the value of the status flag i8 (A), and VN=3. The VH file may include several records for a given ULI if the line identified undergoes several status changes. The records in the VH file are ordered to facilitate the direct creation of a text file for any version in the path.
Referring back to Fig. lB, a version (USER.-l) created in the USER path i8 a copy of (MAIN.0). The VH
file of the MAIN PATH (MVH) is copied to form the VH
file of the USER path (UVH). The UVH is then updated to reflect the change made to (MAIN.0), or equivalently (USER.-l), to form (USER.0).
The creation of (USER.-l) is necessary to create a VH file for the USER path and illustrates the fact that the paths diverge from the module (MAIN.0).
The path of development of both paths up to and includ-ing version (MAIN.0)/(USER.-l) is identical. To reflect this identity, the W H file is built by creating a set of records corresponding to the records in the MVH
file. The ULI and status flag in corresponding records are identical. However, the VNs in the W H records are set to -1.
The creation of (USER.-l) is transparent.
The first version in the USE~ path subject to normal proce~sing is (USER.0), where the line uuu is added to the text file of (MAIN.0).
It i8 possible to reactivate a deleted or replaced line using a backout operation. Thls operation removes changes associated with A particular version of a module. For example, a line identified by a given ULI might be deleted to create the particular module.
If this change were ~ubseguently backed out, then the line would become active again. This activation would ~ 31 6.~62 be reflected in a VH record including the given ULI, the VN of the version created by the backout operation, and the status flag (A).
Fig. 5 depicts three versions 40 of a module 5 formed on a first path. The LN 20 and VH files 22 corre-sponding to these versions are depicted in Fig. 4. The formation of the LN 20 and VH 22 for the first path will now be described.
The LN 20a for the first version 40a includes 1~ all the lines of the first version 40a with each line identified by a ULI 24. The field E in the ULIs is the change tag associated with the operation of creating the first version.
In the second version 40b, the first line of the first ~ersion 40a has been replaced by a new line.
Referring to the second LN 20b, the new line has been added to the LN 20b and is identified by a ULI where the field S1 is the change tag associated with the opera-tion of creating the second version 40b. The LN 20b 20 has been updated to include the lines added in the opera-tion of creating the second version 40b. Note that no lines are ever deleted from the LN 20b.
Referring now to the VH files, the first VH
file 22a includes four records 30, each including one of the ULIs of the lines in the first version and spec-ifying that the lines become active in version 0. The 6econd VH file 22b, includes all the records from the first VH file 22a and additional records indicating the changes entered into the second version 40b. More spe-cifically, the records are sequentially numbered toclarify the following description. The second record h~s been added to indicate that line E.1 has been re-placed in the second version. Note that the records with the same ULI are adjacent. The third record iden-tifies the line that has replaced the deleted line.This record immediately follows the last record indicat-ing a replaced line.
1 31 6~6~
Again, as with the LN 20, the second VH file 22b is formed by updating the first VH file 22a and no records have been deleted.
Referring again to Fig. 5, the third version 5 40c is updated by replacing the first two lines of the second version 40b with new lines. The new LN 20c iB
formed by adding the lines identified by ULIs S2.1 and S2.2 to the second LN 20b. The field S2 in the ULIs is the change tag associated with the operation of creating 10 the third version.
Turning to the third VH file 22c, those records having VNs equal to 0 or 1 are the records from the 6econd VH file 22b. The fourth record indicates that the line identified by S1.1 is replaced in the third 15 version; the sixth record indicates that the line iden-tified by E.2 is replaced in the third version; and, the seventh and eighth records indicate that the lines identified by S2.1 and S2.2 are added in the third ver-sion. The records indicating lines added in the third version immediately follow the last record indicating that a line has been replaced.
At this point, all the information required to create the text file of any version in the path is included in the LN 20c and the VH 22c. Further, the text file of a selected version is created directly without the requirement of creating intermediate ver-~ions.
PROCEDURE FOR CREATING A TEXT FILE
Fig. 6 ls a flow chart illustrating the pro-cedure for creating a selected version, VN=M, in a path.
Referring to Fig. 6, the flrst VH record is read 50 and saved 52. An attempt is then made to read 54 the next VH record. If there are no more records then the end of the file has been reached 56 and the process branches to a closing label (B) 57. Otherwise, the ULI 5 of the saved and read records are then compared 58 to determine whether they are different.
If they are not different then, because of the ordering of the records in the VH file, the second record indi-cates the version number where the identified line is replaced or deleted. Accordingly, the version number of the red record is compared 60 to M to determine whether the identified line was deleted in a version following the version being created. If this version number is greater than M, then the line was deleted in a preceding version or the desired version and is not included in the version M. Accordingly, the process branches back to point A.
If this version number is greater than M, then the line is deleted in a subsequent version in the path. Thus, the value of the status flag is examined 62 and the version number of the saved record is com-pared 64 to M. If the version number in the saved record is less than or equal to M and the value of the status flag is (A) then the identified line becomes active in a preceding or the desired version, is retrieved from the line file, and is included in the text file of the version M. If the version number is greater than M
then this ULI does not affect version M and the process branches back to point A.
Returning to step 58, if the ULIs are differ-ent then the value of the status flag in the saved record is examined 62 and the VN is compared 64 to M. The line identified by the ULI in the saved record is in-cluded 66 in the text file if the value of the status flag in the saved record is (A) and the VN is less than or equal to M. If the version number in the saved record is greater than M, then the identified line was intro-duced in a version following version M and is not present in version M. In this case, the process branches to point A.
Each adjacent pair of records in the VH is processed, with the first record in the pair being the ~ 31 6262 saved record and the second record in the pair being the next read record, as described above until the end of the VH file is reached.
The closing subroutine 57 wlll now be described.
5 The last record is examined to determine if status flag is (A) 57b, and if the VN is less than or equal to M
57c. If both these conditions are met than the llne ldentified by the ULI in the last record is included 57d in version M. Otherwise, the line is not included and the process returns 57e to a calling program.
A specific example of the operation of this process to create ver6ion 1 of Fig. 5 utilizing the VH
and line file 20(c) and 22(c) of Fig. 4 will now be described for the case M=1. Referring now to Figs.
4-6, the ULIs of the first pair of records, the first and second, are not different 58 and the VN of the sec-ond record is not greater than 1 60. Thus, the line identified by the ULI is replaced in version 1 and is not included.
The ULIs of the next pair of records, the second and third, are different 58, the VN in the sec-ond record is equal to M 64, but the status flag is not (A) 62. Thus, the line identified by the ULI is not included.
The ULIs in the next pair of records, the third and fourth, are not different 58, the VN in the fourth record is greater than M 60, the value of the status flag in the third record is (A) 62, and the VN
of the first record is equal to M 64. Accordingly, the line identified by the first record, stu, is included 66 in the text file of version 1. The proces6 for cre-ating the remainder of the text flle for version 1 fol-lows directly from the above description.
It is now apparent that the procedure depict-ed in Fig. 4 i~ able to utilize the VH and LN files fora given path and directly create the text file of a selected version in the path.
1 31 ~o2 DESCRIPTION OF THE MERGE PROCEDURE
An important feature of the present system is the ability to merge changes introduced along two inde-pendent paths into a resulting version. This procedure 5 is illustrated in Fig. 7. The letters ln parentheses are the change tags assoclated wlth the operation of creating each version. These change tags appear in the ULIs of all new lines added in the associated versions.
Versions (T.O), (T.l), and (T.2) form the first three versions ln a TO path 70. The first version (F.O) in a FROM path 72 and version (T.3) in the TO
path both diverge from (T.2). Each path has its own VH
file and shares a single common LN file.
The operation of merging version (F.2), the FROM version, into version (T.4), the TO version, creates a resulting version (T.5) reflecting the changes made along both paths subsequent to their divergence at ver-sion.(T.2). Accordingly, a resulting VH file (RVH) must be created so text files of all versions in the TO
20 path, including the resulting version (T.5), may be created from the RVH file utilizing the procedure de-ficribed with reference to Fig. 6.
The change licts for (F.2) and (T.4) are re-guired to perform the merge operation. A change list is a list of the change tags which have been applied to create the version owning the list. Table 1 depicts the change lists for versions (F.2) and (T.4).
VERSION CHANGE LIST
(F.2) A,B,C,S,T,U
(T.4) A,B,C,DE
The procedure for creating the ~VH file in-cludes the steps of generating a common list (tags in both change lists), a TO list (change list for the TO
17t~6262 version), and a FROM list (change list for the FROM
version). Table 2 depicts the change tags in these lists.
COMMON LIST A,B,C
FROM LIST A,B,C,S,T,U
TO LIST A,B,~,D,E
The status of a given line in the resulting version depends on the change tag included in the ULI
identifying the given line. If the change tag is in the common list, then the status of the given line in the resulting version depends on the status of the given line in both (F.2) and (T.4) and iR determined by a set of predetermined rules.
The predetermined set of rules utilized to determine the status of the given 11ne identified by a ULI having a change tag in the common list is represented in Fig. 8 by a matrix 83. Referring to Fig. 8, the matrix 83 has its rows labelled by the status of the given line in the FROM path and its columns labelled by the status of the given line in the TO path. The ele-25 ments in the matrix 83 are set forth in boxes 84 seguen-tially numbered from O to 35. The meaning of the symbols utilized to label the rows and columns of the matrix are defined in Table 3. The symbols utilized to define the matrix elements 86 are defined in Table 4. An (*) in a box 84 indicates that a new record will be written to the RVH file. The method for utilizing the matrix will be described more fully below.
SActive,c=): line was active when files diverged/prev-iously merged and has not been altered since then;
18 ~316262 (Active,>): a backout of a change, resulted in a change to this ULI since the files diverged/previously merged;
(Inactive delete,<=): line was deleted when files di-5 verged/previously merged and ha~ not been altered since then;
(Inactive delete,>): line was deleted since the files diverged/previously merged;
(Inactive replace,<=): line was replaced when files diverged/previously merged and has not been altered since then;
(Inactive replace,>): line was replaced since the files diverged/previously merged.
A: the result of the merge is that the ULI is left active; no new VH record is written;
I: the result of the merge is that the ULI is left inactive; no new VH record is written;
R: the result of the merge is that the ULI i9 left replaced; no new VH record is written;
A*: create a new VH record indicating that the ULI is now active;
I*: create a new VH record indicating that the ULI is now deleted;
R*: create a new VH record indicat~ng that the ULI is now replaced.
The symbol6 ~= and > indicate the result of a comparison between the change which created the VH record being considered and the common list of changes. This determines whether the VH record' B information was already 5 known when the paths diverged or were la~t merged, or whether the information ls new since the last such point of divergence.
The mechanism currently used for deciding when a change occurred ln relation to the last divergence 10 point involves comparing the version number in a VH
record with a "common version" on the path currently being considered.
The "common version" i6 determined by compar-ing the common list of tags with the list of tags present in each significant version of the TO or FROM path, starting at the earliest version. The first such version which includes all common tags, or includes tags not found in the common list, i8 the desired common ver~ion.
Thus for a simple case, where version O of a new path is being merged back into the path from which it diverged, the common version would be -1.
The procedure for merging two modules will now be described with reference to Figs. 9 through 18.
Fig. 9 illustrates a merge operation from version (F.O) (FROM version) in a FROM path to version (M.l) (TO ver-sion) in a MAIN path. The text file and ULIs for each version are depicted. Additionally, the VH file gener-ated when each version was created iB shown associated with the various versions. The change lists for (F.O) and (M.1) are depicted in Table 5 and the common, TO, and FROM lists are depicted in Table 6.
VERSION CHANGE LIST
(F.0) E,F0 (M.l) E,Ml l 3l 62 62 COMMON LIST E
FROM LIST E,FO
TO LIST E,M1 The VH flle associated with (F.O) i8 the FVH, the VH file associated with (M.l) is the TVH, and the VH file associated with (M.2) is the RVH.
Fig. 10 i8 a flow chart listlng the steps in the Merge-Main routine which coordinates the overall merge operation. This program invokes numerous subrou-tines which perform the detailed operations necessary to merge two paths of a module.
Referring now to Fig. 10, the first step lOO
is to build a list of the module names to lnclude and exclude from the merge. In the present example, module E is included in the merge. Next, the merge list is tested 102 to determine whether there are more modules to merge. If no, then the program branches to a closing label A 103. If yes, the LN file for module E, and VH
files for the FROM and TO variants are opened 104 and a new VH file (RVH) is created 106 for the results of the merge.
Next, the procedure for merging the variant paths is called 108. These procedures are described below. If the merge is successful 110 then the variant record is updated 112, lf not the program jumps to step 102. Next, a new record describing the version is cre-ated 114 and and the LN file and VH files are closed 116. The program then returns to step 102. If there are no more modules to be merged, then the closlng por-tion 103 is executed.
Referring to the closing, a change record is built 103a to reflect the merge, the new VH file is renamed and the old one purged 103b, and the results of the merges are reported 103c.
21 t3l626~-) Fig. 11 is a flow chart listing the steps of the MERGE-VARIAMT-PATHS procedure. This procedure con-trols the mechanics of merging two paths of one module.
Referring to Fig. 11, the TO list, FROM list, and common list for (F.0) and (M.l) are generated 310. The contents of these lists are set forth above ln Tables 5 and 6.
Next, the lists are examined 320 to determine whether the FROM list i8 a subset of the TO list. If yes, than there i 6 no need to proceed further because the 6tatus of all lines in the FROM version have already been used in determining the status of the lines in the TO version.
If not, then the first record from the TVH
and FVH files are read 340. Next, it is determined that the end of the file has not been reached 350. The pro-cedure then tests the change tags in the ULIs of theread records to determine whether the tags in the VLIs in the first TVH and FVH records are in the common list 360, whether only the tag in the firqt TVH record is in the common li~t 362, whether only the tag from the first ~0 FVH record is in the common list 364, or whether neither the tag in the first FVH record nor the the tag in the first TVH record is in the common list. Depending on which condition is true, the appropriate subroutine 368, 370, 372, or 374 is called.
The operation of the MERGE-VARIANT-PATHS sub-routine 300 will be described with reference to the example illustrated in Fig. 9. The first record in the TVH file (E.0 0 A) and in the FVH file (E.0 -l A) are read 340. The change tag (E) in both records are in the common list 360 and the subroutine PROCESS-ULI-IN-BOTH-PATHS ~s called 368.
Fig. 13 is a flow chart of this subroutine.
Referrin~ to Fig. 13, the ULI 6 in both records match 502. The read (first) TVH record is written to the new VH file 504 and the value of the status flag (A) of the record is saved 506. The next (second) TVH record (E.1 0 A) is read 508 and the saved ULI and ULI of the next 1 31 6~k?
read record are compared 510. In thls case, the ULIs are different.
The read (first) FVH record is then examined to determine whether the version number in the record 5 i8 less than or equal to the vers~on number of (F.0) 512, and iE BO, the ~tatus flag of the record i6 6aved 513. In this case, the version number (-l) in the record i6 less than the version number (O) of the FROM version and the 6tatus flag (A) i8 saved. The next (second) 10 FVH record (E.l -l A) is read 514 and the ULIs of the saved and next read FROM records are compared 516.
In this case, the ULIs are different and the ~aved status flags are utilized 518 to execute the case statement which implements the predetermined set of rules. As described above, this set of rules is shown as a matrix. Referring to Fig. 8, and Tables 5 and 6, for both paths the line was active before divergence and no changes have been made since then (A,<=). Ac-cordingly, case statement 0 is executed and the line is active in the resulti~g version. The result of the subroutine is that the first record in the RVH file is the same as the first record in TVH file and no new - record is created. The subroutine then returns 520 to the calling subroutine.
The steps 350, 360, and 368 of the MERGE-VARIANT-PATHS procedure are then repeated for the sec-ond records in TVH and FVH files and the subroutine PROCESS-ULIS-IN-BOTH-PATHS 368 is called. From the structure of the TVH and FVH files it is apparent that the first five records in those files are processed as described above and that the first five records in the RVH file are the same as the flrst flve records ln the TVH file.
Referring to Fig. 13, after the fifth TVH
record is written 504 and the sixth TVH record is read ~08, the ULIs of the two records are compared 510. In this case the ULIs are not different and the subroutine 23 1 31 626~
branches back to step 504. The sixth TVH record (E.4 1 R) iB written to the RVH file, the status flag (R) is 6aved 506, and the seventh TVH record (FO.O O A) i6 read 50~. The ULIs are then compared 510 and found 5 to ~e different.
The sixth FVH record (E.4 0 R) ls read 514 and its ULI is compared to the ULI of the fifth record 516. The ULI 5 are the same so the subroutine branches back to 6tep 512. The status flag (R) of the sixth record iB saved 513 and the seventh FVH (FO.O O A) record is read 516. The ULIs of the sixth and 6eventh records are compared 516 and found to be different.
The saved status flags are then utilized 518 to execute on of the case statements of the predetermined 6et of rules. As described above, this set of rules is implemented as a case statement based on the matrix shown in Fig. 8. Referring to Fig. 8, and Tables 5 and 6, for both paths the line was replaced since diver-gence (R,~). Accordingly, case statement 35 iB executed, the line is replaced in the resultlng version, a new record is generated and written to the ~VH file, and a conflict message is generated. The result of the execut-ing the subroutine iB that the record (E.4 2 R) is generated and written as the seventh RVH record. The subroutine then returns 520 to the calling subroutine.
The change tags of the ULI B in the seventh TV~ and FVH records are compared to the change tags in the common list and it iB determined that neither tag is ln the common list 360,362,364. Accordingly, the subroutine NEW-LINES-IN-BOTH-PATHS 18 called 374.
Fig. 17 iB a flow chart for this subroutine.
In Fig. 17, first the TVH file records are processed 900 and then the FVH file records are processed 910.
If it iB determined that llnes from both paths are ac-tive in the resulting version 920, then a warning mes-sage is printed and the active lines are displayed 922.
This feature calls attention to the possible conflict between the lines added along the independent paths and provides for a ~ulck review of the lines added. The method of ~eeping track of these active lines is described below.
The subroutine PROCESS-ULI-IN-TO-PATH i B called in step 900. Fig. 14 is a flow chart for this ~ubroutine.
In Fig. 14, the seventh TVH record is written to the new VH 600, the eighth TVH record i8 read 602, and the ULIs of the two records are compared 60~. In this case 10 the ULIs are different, the status flag in the ~eventh record is examined 608 to determine whether the value of the status flag is (A), and active-TO-ULI-count is incremented 608. This count keeps track of new ULIs added in the TO path ~ince the point of divergence and which are active. The change tag of the ULI in the eighth record is then compared to the change tags in the common list 610 to determine whether the ULI is in the common list. In this case it iB not and the sub-routine branches back to step 600.
The processing of the eighth through eleventh TVH records is the same as described above with the result that these records become the ninth through twelfth records of the RVH. The twelfth TVH record (E.5 0 A) is read 602, the count is incremented 609, it is deter-25 mined that the new ULI read is in the common list 610, and the subroutine returns to step 900 of the calling subroutine. The subroutine PROCESS-ULI-IN-FROM-PATH is then called 910.
Eig. 16 i8 a flow chart of that subroutine.
In Fig. 1~, the ~tatus flag (A) of the seventh FVH record i6 ~aved 800 because the version number in the record is equal to version number of the FROM version, the eighth FVH record is read B10, ~nd ULIs of the records are compared 812. In this case, the ULIs are different and a new VH record is built 814 that reflects the last saved state. This new VH record, (FO.O 2 A), indicates that the line identified by the ULI (FO.O) becomes active l 3t 6262 in version 2, the resulting version, in the T0 path as a result of the merge operation and which are active.
The record built is written to the RV~ file 816 a~d the ~tatus flag of the record i8 examined 818 to determine 5 whether its value is (A). If BO, nctive-FROM-ULI-count i6 incremented 820. This count keeps track of new lines added from the FROM path during the merge operation and which are active. The change tag of the ULI in the eighth record iB then compared 822 to the change tags 10 in the common list to determine whether the ULI i~ in the common list. In this ca6e it i8 not and the sub-routine branches back to step 800.
The processing of the eighth through tenth FVH records is the same as de~cribed above with the result that the fourteenth through 6ixteenth records are built reflecting that these lines become active as a result of the merge.
It is determined 822 th~t the change tag in the ULI of the eleventh FVH record is in the common list and the subroutine returns 824 to step 910 of the calling ~ubroutine. The counts generated in the two called subroutines indicate that new lines in both paths become active in the resulting version and the warning message is printed and the new lines are displayed 922.
The subroutine then returns to step 350 of the calling procedure.
It is then determined that the change tags of the eleventh FVH record and twelfth TVH record are in the common list 360, and the procedure PROCESS-ULI-IN-BOTH-PATHS described above are utilized to write the twelfth through fifteenth TVH records to the new VH.
It 1~ then determined that the end of a VH file is reached and part (B), Fig. 12, ls executed to complete the merge.
Fig. 18 depicts the subroutine SKIP-THIS-MERGE-ULI. This subroutine is not used in the above example but may be called by the 6ubroutine PROCESS-FROM-PATH-26 l 31 6267 VH-RECS when the FROM version is not the last version created in the FROM path. Thi 6 6ubroutine prevents changes made in the FROM path subsequent to the creation of the F~OM version from being included in the resulting 5 version.
The generation of change lists and determina-tion of the point of divergence for the example of Fig. 9 was possible from inspection. However for more complicated cases where several independent paths exi Bt and merges between paths have been made prevlously, the generation of the list is more difficult. Fig. 20 is a schematic diagram depicting such a complex case. The se of the change list to generate the common list is important to the above-described merge procedure and facilitates the generation of conflict messages and other advantageous features.
A generalized procedure for building the change list for a version will now be described. This procedure i8 an application of graph theory. A signiflcant version 20 i8 defined as either the first ver~ion in a variant (i.e. version 0), or was the version from which a new variant was created, or was the version created as the result of a merge operation, or was the version from which a merge was done. All slgnificant versions are candidates for being the common verQions in a merge operation.
The versions of the module are considered as part of a directed, acyclic graph. All versions of the module are descendents of the original version (version O) in the original path. Each version can be created in only one of four ways, i.e., a) by adding a module to the database; b) by checking ln a checked out ver-sion; c) by creating a new path; or, d) as the result of a merge operation.
The algorithm for creating the change tags starts by representing the graph of versions as a graph of significant versions. Each such version is assigned 1 31 626?
its own change list, which is initially empty. The first (earliest) significant node has its own change tag placed in its change list, Next, the call VISIT(ear-liest node~ is made, where VISIT is the following recur-5 sive procedure:
procedure VISIT(j) { j i8 a node in the graph}
begin for each node k, where the link (j->k) exists, do begin if (k is the result of a merge) and (change tag for node j is not in list(k))then list(k) ~- COMBINE(j,k) else list(k) ~- COMBINElj,k) call VISIT(k) end end.
Where the procedure COMBINE is:
procedure COMBINE(x,y) {x and y are nodes, and this procedure returns a change list begin make resulting list empty add every change tag in list(x) to resulting list add every change tag ln list(y) to resultlng li~t add change tag for node x to resulting list return resulting list end.
1 3t 626~
The invention has now been described in terms of preferred embodiments. Modifications and substitu-tions will now be apparent to persons of ordinary skill ln the art. In particular, the rules for processing 5 ULIs in both the TO and FROM paths may be varied accord-ing to specific systems _equirements. Therefore, it is not intended that the ~nvention be limited except as provided by the appended claims.
Claims (10)
1. A method for directly creating a text file of a desired version of a stored module, with the version comprising a plurality of lines of text and included in a development path including several versions, said method comprising the steps of:
storing all lines active in the several versions in the path in an indexed line file; and retrieving only those lines active in the desired version from the line file for inclusion in the text file.
storing all lines active in the several versions in the path in an indexed line file; and retrieving only those lines active in the desired version from the line file for inclusion in the text file.
2. A method for storing a desired version of a module, where the desired version comprises a plurality of lines of text and is included in a given path which is one of many possible paths, with each path including an ordered set of versions of a common module, with each version identified by a version number, with each version in a path evolving from an immediately preceding version, and where a status history of activations and deletions of each line in a path is stored in a variant history file for the path, said method comprising the steps of:
storing all lines active in all versions in all paths in an indexed line file;
identifying each line in said indexed line file by a unique line identifier (ULI); and storing a set of records, in the variant history file for the given path, for each ULI identifying a line active in any version in the given path, with each record in a set indicating a version number of a version in a given path where the line identified by the ULI becomes active, or a version number of a version in the given path where the line identified by the ULI i deleted.
storing all lines active in all versions in all paths in an indexed line file;
identifying each line in said indexed line file by a unique line identifier (ULI); and storing a set of records, in the variant history file for the given path, for each ULI identifying a line active in any version in the given path, with each record in a set indicating a version number of a version in a given path where the line identified by the ULI becomes active, or a version number of a version in the given path where the line identified by the ULI i deleted.
3. A method for creating a text file of a desired version of a module, where the desired version is included in a given one of many possible paths, with each path including an ordered set of versions, each identified by a version number, of a common module, with each version in a path evolving from an immediately preceding version, and where a status history of activations and deletions of each line active in any version in a path is stored in a variant history file for the path, and where text of lines active in all versions in all paths is stored in an indexed line file with each line in the indexed line file identified by a unique line identifier (ULI), said method comprising the steps of, identifying the given path in which the desired version is included and the version number of the desired version in said given path;
searching the variant history file of the given path to determine which lines in the line file are active in the desired version; and retrieving, from said line file, the text of lines determined to be active in the desired version.
searching the variant history file of the given path to determine which lines in the line file are active in the desired version; and retrieving, from said line file, the text of lines determined to be active in the desired version.
4. The method of claim 3 wherein:
the variant history file of the given path includes an ordered set of records identifying a line active in any version in the given path, with each record in a set comprising an included ULI and indicating a version number in a given path where the line identified by the included ULI becomes active, or a version number in the given path where the line identified by the included ULI is deleted; with the records in said variant history file ordered so that the record indicating a version number of a first given version, in which a given line becomes active, immediately precedes a record indicating the version number of a second given version in which said given line is deleted, and where the records of lines made active in the second given version immediately follow the last record indicating a line is deleted in the second given version, and wherein said step of searching comprises:
reading an adjacent pair of records including a preceding and a following record in said variant history file;
determining whether the included ULIs in said adjacent pair of records are the same;
if the included ULIs are the same, including the identified line in the desired version only if the version number indicated by said following record is greater than the version number of said desired version, if the version number indicated by the preceding record in the pair is less than or equal to the version number of the desired version, and if the identified line indicated by the preceding record in the pair is active; and if the included ULIs are different, including the identified line in the desired version only if the version number indicated by said preceding record in the pair is less than or equal to the version number of the desired version and if the identified line indicated by the preceding record in the pair is active.
the variant history file of the given path includes an ordered set of records identifying a line active in any version in the given path, with each record in a set comprising an included ULI and indicating a version number in a given path where the line identified by the included ULI becomes active, or a version number in the given path where the line identified by the included ULI is deleted; with the records in said variant history file ordered so that the record indicating a version number of a first given version, in which a given line becomes active, immediately precedes a record indicating the version number of a second given version in which said given line is deleted, and where the records of lines made active in the second given version immediately follow the last record indicating a line is deleted in the second given version, and wherein said step of searching comprises:
reading an adjacent pair of records including a preceding and a following record in said variant history file;
determining whether the included ULIs in said adjacent pair of records are the same;
if the included ULIs are the same, including the identified line in the desired version only if the version number indicated by said following record is greater than the version number of said desired version, if the version number indicated by the preceding record in the pair is less than or equal to the version number of the desired version, and if the identified line indicated by the preceding record in the pair is active; and if the included ULIs are different, including the identified line in the desired version only if the version number indicated by said preceding record in the pair is less than or equal to the version number of the desired version and if the identified line indicated by the preceding record in the pair is active.
5. The method of claim 3 wherein:
the variant history file of the given path includes a set of records identifying a line active in any version in the given path, with each record in a set comprising an included ULI
and indicating one of the version numbers of the versions in a given path where the line identified by the included ULI becomes active, or one of the version numbers of the versions in the given path where the line identified by the included ULI is deleted;
and wherein said step of searching comprises the steps of:
ordering the records in said variant history file so that the record indicating a version number of a first given version, in which a given line becomes active, immediately precedes the record indicating the version number of a second given version in which said given line is deleted, and where the records of lines made active in the second given version immediately follow the last record indicating a line is deleted in the second given version;
reading an adjacent pair of records including a preceding and a following record in said variant history file;
determining whether the included ULIs in said adjacent pair of records are the same;
if the included ULIs are the same, including the identified line in the desired version if the version number indicated by said following record is greater than the version number of said desired version, if the version number indicated by the preceding record in the pair is less than or equal to the version number of the desired version, and if the identified line indicated by the preceding record in the pair is active; and if the included ULIs are different, including the identified line in the desired version if the version number indicated by said preceding record in the pair is less than or equal to the version number of the desired version and if the identified line indicated by the preceding record in the pair is active.
the variant history file of the given path includes a set of records identifying a line active in any version in the given path, with each record in a set comprising an included ULI
and indicating one of the version numbers of the versions in a given path where the line identified by the included ULI becomes active, or one of the version numbers of the versions in the given path where the line identified by the included ULI is deleted;
and wherein said step of searching comprises the steps of:
ordering the records in said variant history file so that the record indicating a version number of a first given version, in which a given line becomes active, immediately precedes the record indicating the version number of a second given version in which said given line is deleted, and where the records of lines made active in the second given version immediately follow the last record indicating a line is deleted in the second given version;
reading an adjacent pair of records including a preceding and a following record in said variant history file;
determining whether the included ULIs in said adjacent pair of records are the same;
if the included ULIs are the same, including the identified line in the desired version if the version number indicated by said following record is greater than the version number of said desired version, if the version number indicated by the preceding record in the pair is less than or equal to the version number of the desired version, and if the identified line indicated by the preceding record in the pair is active; and if the included ULIs are different, including the identified line in the desired version if the version number indicated by said preceding record in the pair is less than or equal to the version number of the desired version and if the identified line indicated by the preceding record in the pair is active.
6. In a version control system which stores several versions of a module, where each version is included in one of many possible paths, with each path including an ordered set of versions, each identified by a version number, of a common module, with each version in a path evolving from the immediately preceding version, with a unique change tag associated with the operation of creating a given version, where the text of all lines active in all versions along all paths of the module are stored in an indexed line file and identified by a unique line identifier (ULI), with each ULI including a tag field identifying a version and an index field, and where the status history of the activation and deletions of each line in a path are stored in a variant history file for the path, with each record in the variant history file including a ULI, a version number identifying a version in the path, and a status flag having a value indicating that the line identified by the ULI becomes active, is replaced, or is deleted in the identified version, a method for building a resulting variant history file for a TO path to reflect the merge of a selected version in a FROM path into a TO version, which is the last version in the TO path, to form a resulting version in the TO path, said method comprising the steps of:
providing a TO path variant history file and a FROM path variant history file;
building a TO change list for said TO version;
building a FROM change list for the selected version in the FROM path;
building a common list of the change tags included in both said FROM change list and said TO change list;
writing, in the resulting variant history file, a first set of TO variant history records, with the first set consisting of only those TO variant history records that include ULIs with change tags included in said TO change list but not included in said common list;
identifying a second set of FROM variant history records, with said second set consisting of only those FROM
variant history records that include ULIs with change tags in said FROM change list but not included in any record in said TO change list or said common list, and, for each of those ULIs, only the FROM variant history record having the greatest version number that is less than or equal to the version number of the selected version in the FROM path;
modifying said second set of FROM variant history records so that the version number in each record is equal to the version number of the resulting version in the TO path;
writing, to the resulting variant history file, said modified second set of FROM variant history records;
writing, to the resulting variant history file, a third set of TO variant history records, with said third set consisting of only those TO records that include ULIs in said common list and that are included in a record in the TO variant history file and the FROM variant history file; and generating a fourth set of resulting variant history records, with each record in said fourth set associated with a selected one of the records in said third set and including the same ULI as the associated record, with the selection of a given selected record from said third set and the assignment of the value of the status flag in the fourth set record associated with the given selected record determined by the values of the version numbers and status flags of records in the FROM and TO variant history files that have the same ULI as the given selected third set record and by a predetermined set of rules applied to those values.
providing a TO path variant history file and a FROM path variant history file;
building a TO change list for said TO version;
building a FROM change list for the selected version in the FROM path;
building a common list of the change tags included in both said FROM change list and said TO change list;
writing, in the resulting variant history file, a first set of TO variant history records, with the first set consisting of only those TO variant history records that include ULIs with change tags included in said TO change list but not included in said common list;
identifying a second set of FROM variant history records, with said second set consisting of only those FROM
variant history records that include ULIs with change tags in said FROM change list but not included in any record in said TO change list or said common list, and, for each of those ULIs, only the FROM variant history record having the greatest version number that is less than or equal to the version number of the selected version in the FROM path;
modifying said second set of FROM variant history records so that the version number in each record is equal to the version number of the resulting version in the TO path;
writing, to the resulting variant history file, said modified second set of FROM variant history records;
writing, to the resulting variant history file, a third set of TO variant history records, with said third set consisting of only those TO records that include ULIs in said common list and that are included in a record in the TO variant history file and the FROM variant history file; and generating a fourth set of resulting variant history records, with each record in said fourth set associated with a selected one of the records in said third set and including the same ULI as the associated record, with the selection of a given selected record from said third set and the assignment of the value of the status flag in the fourth set record associated with the given selected record determined by the values of the version numbers and status flags of records in the FROM and TO variant history files that have the same ULI as the given selected third set record and by a predetermined set of rules applied to those values.
7. In a version control system which stores several versions of a module, where each version is included in one of many possible paths, with each path including an ordered set of versions, each identified by a version number, of a common module, with each version in a path evolving from the immediately preceding version, with a unique change tag associated with the operation of creating each version, where the text of all lines active in all versions along all paths of the module are stored in an indexed line file and identified by a unique line identifier (ULI), with each ULI including a change tag and an index field, a method for merging a selected version in a FROM path into a TO
version, which is the last version in the TO path, to form the text file of a resulting version in the TO path, said method comprising the steps of:
building a common list of change tags included in ULIs identifying lines that have been active in both the TO and FROM
paths;
including, in the text file of the resulting version, lines identified by ULIs having change tags in said common list according to the status, in the TO and FROM versions, of the lines identified and according to a set of predetermined rules.
version, which is the last version in the TO path, to form the text file of a resulting version in the TO path, said method comprising the steps of:
building a common list of change tags included in ULIs identifying lines that have been active in both the TO and FROM
paths;
including, in the text file of the resulting version, lines identified by ULIs having change tags in said common list according to the status, in the TO and FROM versions, of the lines identified and according to a set of predetermined rules.
8. A computer operating under control of a stored program for allowing a user to store a source file module, to create and store new versions of the module, to create and name independent paths of development of the module, with each path being an ordered set of versions, comprising:
an I/O unit;
memory means for storing a source file module, new versions of the source file module, an indexed line file, and a variant history file;
a user interface, connected to the memory means by said I/O unit, for accessing existing versions from said memory and storing modified versions in said memory;
CPU means, connected to the memory means by said I/O
unit, for executing stored program instructions to build an indexed line file, stored in the memory, including the text of all lines active in all versions in all paths, with each line in said indexed line file identified by a unique line identifier (ULI), to build a variant history file, stored in the memory, including a set of records associated with each ULI identifying a line included in any version along a given path, where each record in a given set of records associated with a given ULI indicates a version in the given path where the line identified by the ULI
became active or a version in the given path where the ULI was deleted; and for utilizing said variant history file and indexed line file to directly generate the text file of a desired version in said given path without creating any intermediate versions.
an I/O unit;
memory means for storing a source file module, new versions of the source file module, an indexed line file, and a variant history file;
a user interface, connected to the memory means by said I/O unit, for accessing existing versions from said memory and storing modified versions in said memory;
CPU means, connected to the memory means by said I/O
unit, for executing stored program instructions to build an indexed line file, stored in the memory, including the text of all lines active in all versions in all paths, with each line in said indexed line file identified by a unique line identifier (ULI), to build a variant history file, stored in the memory, including a set of records associated with each ULI identifying a line included in any version along a given path, where each record in a given set of records associated with a given ULI indicates a version in the given path where the line identified by the ULI
became active or a version in the given path where the ULI was deleted; and for utilizing said variant history file and indexed line file to directly generate the text file of a desired version in said given path without creating any intermediate versions.
9. A computer operating under control of a stored program for allowing a user to store a source file module, to create and store new versions of the module, to create and name independent paths of development of the module, with each path being an ordered set of versions, and with the versions in the path identified by version numbers, and for building, in the memory, an indexed line file, including the text of all lines active in all versions along all paths of the module, and a variant history file for given path, wherein the improvement comprises:
a memory for storing an indexed line file, a variant history file, and program data;
a CPU, connected to said memory, for executing said program data to create an indexed line file having a unique line identifier associated with each line in the line file and a variant history file including an ordered set of records, with each record including a unique line identifier, associated with a line active in one of the versions in the given path, and indicating one of the version numbers in the given path where the line identified by the unique line identifier became active or one of the version numbers in the given path where the line identified by the unique line identifier was deleted.
a memory for storing an indexed line file, a variant history file, and program data;
a CPU, connected to said memory, for executing said program data to create an indexed line file having a unique line identifier associated with each line in the line file and a variant history file including an ordered set of records, with each record including a unique line identifier, associated with a line active in one of the versions in the given path, and indicating one of the version numbers in the given path where the line identified by the unique line identifier became active or one of the version numbers in the given path where the line identified by the unique line identifier was deleted.
10. The computer of claim 9 also for generating a change tag associated with the operation of creating a new version, wherein said program data when executed by said CPU causes each unique line identifier to include a change tag associated with the operation of creating the version where the line identified by the unique line identifier first became active; and causes said variant history file to have its records ordered so that record indicating a version number of a first given version, in which a given line becomes active, immediately precedes record indicating the version number of a second given version in which said given line is deleted, and where records of lines made active in the second given version immediately follow a last record indicating a line is deleted in the second given version.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US183,190 | 1988-04-26 | ||
| US07/183,190 US4912637A (en) | 1988-04-26 | 1988-04-26 | Version management tool |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA1316262C true CA1316262C (en) | 1993-04-13 |
Family
ID=22671824
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA000597671A Expired - Fee Related CA1316262C (en) | 1988-04-26 | 1989-04-25 | Version management tool |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US4912637A (en) |
| EP (1) | EP0339901B1 (en) |
| JP (1) | JPH0228831A (en) |
| AU (1) | AU615536B2 (en) |
| CA (1) | CA1316262C (en) |
| DE (1) | DE68925746T2 (en) |
Families Citing this family (304)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5438511A (en) * | 1988-10-19 | 1995-08-01 | Xerox Corporation | Disjunctive unification |
| US5159669A (en) * | 1988-12-15 | 1992-10-27 | Xerox Corporation | Automatically creating a second workspace operation record including history data and a unit ID based on a first workspace operation |
| CA1323448C (en) * | 1989-02-24 | 1993-10-19 | Terrence C. Miller | Method and apparatus for translucent file system |
| EP0458495A3 (en) * | 1990-05-21 | 1993-04-14 | Texas Instruments Incorporated | Apparatus and method for managing versions and configurations of persistent and transient objects |
| US5230075A (en) * | 1990-06-04 | 1993-07-20 | General Electric Company | Database shadowing system with data tags that select an operation of the save command |
| EP0463251A1 (en) * | 1990-06-28 | 1992-01-02 | International Business Machines Corporation | Software installation |
| JP3059467B2 (en) * | 1990-07-17 | 2000-07-04 | シャープ株式会社 | File management device |
| US5386553A (en) * | 1990-10-10 | 1995-01-31 | Fuji Xerox Co., Ltd. | Disk file updating control device and method using updating data stored in a first-in-first-out queue |
| US5278979A (en) * | 1990-12-20 | 1994-01-11 | International Business Machines Corp. | Version management system using pointers shared by a plurality of versions for indicating active lines of a version |
| JP2595817B2 (en) * | 1991-01-17 | 1997-04-02 | ヤマハ株式会社 | Method of controlling information in secondary storage device and electronic apparatus having secondary storage device |
| JP2993528B2 (en) * | 1991-05-18 | 1999-12-20 | 富士通株式会社 | Text management and restoration method |
| EP0528617B1 (en) * | 1991-08-19 | 1999-12-22 | Sun Microsystems, Inc. | Method and apparatus for change control in multiple development environments. |
| US5671428A (en) * | 1991-08-28 | 1997-09-23 | Kabushiki Kaisha Toshiba | Collaborative document processing system with version and comment management |
| US5491819A (en) * | 1991-09-05 | 1996-02-13 | International Business Machines Corporation | System and method for merging and separating attributes of consoles |
| US5628006A (en) * | 1991-09-05 | 1997-05-06 | International Business Machines Corporation | Computer program product and program storage device for merging and separating attributes of consoles |
| US5377323A (en) * | 1991-09-13 | 1994-12-27 | Sun Microsytems, Inc. | Apparatus and method for a federated naming system which can resolve a composite name composed of names from any number of disparate naming systems |
| EP0541281B1 (en) * | 1991-11-04 | 1998-04-29 | Commvault Systems, Inc. | Incremental-computer-file backup using signatures |
| US5357631A (en) * | 1991-12-09 | 1994-10-18 | International Business Machines Corporation | Method and system for creating and maintaining multiple document versions in a data processing system library |
| US5241675A (en) * | 1992-04-09 | 1993-08-31 | Bell Communications Research, Inc. | Method for enforcing the serialization of global multidatabase transactions through committing only on consistent subtransaction serialization by the local database managers |
| JP2502023B2 (en) * | 1992-04-13 | 1996-05-29 | インターナショナル・ビジネス・マシーンズ・コーポレイション | Data file comparison method and system |
| US5504879A (en) * | 1992-07-16 | 1996-04-02 | International Business Machines Corporation | Resolution of relationship source and target in a versioned database management system |
| US5592661A (en) * | 1992-07-16 | 1997-01-07 | International Business Machines Corporation | Detection of independent changes via change identifiers in a versioned database management system |
| US5386559A (en) * | 1992-07-16 | 1995-01-31 | International Business Machines Corporation | Variant domains and variant maps in a versioned database management system |
| US5579223A (en) * | 1992-12-24 | 1996-11-26 | Microsoft Corporation | Method and system for incorporating modifications made to a computer program into a translated version of the computer program |
| US5649200A (en) * | 1993-01-08 | 1997-07-15 | Atria Software, Inc. | Dynamic rule-based version control system |
| US5574898A (en) * | 1993-01-08 | 1996-11-12 | Atria Software, Inc. | Dynamic software version auditor which monitors a process to provide a list of objects that are accessed |
| US5522079A (en) * | 1993-06-14 | 1996-05-28 | International Business Machines Corporation | Compiler merging new and preexisting modules while preserving function order |
| US5634114A (en) * | 1993-11-18 | 1997-05-27 | Intel Corporation | Dynamic link library version negotiation |
| US5611066A (en) * | 1994-02-28 | 1997-03-11 | Data/Ware Development, Inc. | System for creating related sets via once caching common file with each unique control file associated within the set to create a unique record image |
| US6760840B1 (en) * | 1994-03-15 | 2004-07-06 | Kabushiki Kaisha Toshiba | File editing system and shared file editing system with file content secrecy, file version management, and asynchronous editing |
| US5835601A (en) * | 1994-03-15 | 1998-11-10 | Kabushiki Kaisha Toshiba | File editing system and shared file editing system with file content secrecy, file version management, and asynchronous editing |
| US5664183A (en) * | 1994-04-19 | 1997-09-02 | International Business Machines Corporation | Application of groupware to ISO 9000 registration via facilitated work sessions |
| JP3727076B2 (en) * | 1994-08-25 | 2005-12-14 | 富士通株式会社 | Program management method and apparatus |
| US5737600A (en) * | 1994-09-12 | 1998-04-07 | International Business Machines Corporation | Method and system for log management in a coupled data processing system |
| US5574906A (en) * | 1994-10-24 | 1996-11-12 | International Business Machines Corporation | System and method for reducing storage requirement in backup subsystems utilizing segmented compression and differencing |
| US5634052A (en) * | 1994-10-24 | 1997-05-27 | International Business Machines Corporation | System for reducing storage requirements and transmission loads in a backup subsystem in client-server environment by transmitting only delta files from client to server |
| JPH08171482A (en) * | 1994-10-29 | 1996-07-02 | Mitsubishi Electric Corp | System for generating version of program |
| CA2137492C (en) * | 1994-12-07 | 1998-07-28 | Lenny Kwok-Ming Hon | System for and method of providing delta-versioning of the contents of pcte file objects |
| US5675802A (en) * | 1995-03-31 | 1997-10-07 | Pure Atria Corporation | Version control system for geographically distributed software development |
| US5694596A (en) * | 1995-05-25 | 1997-12-02 | Kangaroo, Inc. | On-line database updating network system and method |
| US5671398A (en) * | 1995-06-09 | 1997-09-23 | Unisys Corporation | Method for collapsing a version tree which depicts a history of system data and processes for an enterprise |
| US5805899A (en) * | 1995-07-06 | 1998-09-08 | Sun Microsystems, Inc. | Method and apparatus for internal versioning of objects using a mapfile |
| US6366933B1 (en) * | 1995-10-27 | 2002-04-02 | At&T Corp. | Method and apparatus for tracking and viewing changes on the web |
| US5745906A (en) * | 1995-11-14 | 1998-04-28 | Deltatech Research, Inc. | Method and apparatus for merging delta streams to reconstruct a computer file |
| US5729743A (en) * | 1995-11-17 | 1998-03-17 | Deltatech Research, Inc. | Computer apparatus and method for merging system deltas |
| US6349407B1 (en) * | 1995-12-29 | 2002-02-19 | Sun Microsystems, Incorporated | Method and apparatus for re-introducing version control |
| US5950210A (en) * | 1996-01-29 | 1999-09-07 | Nelson; Paul M. | Database row version differentiation process |
| US5706510A (en) * | 1996-03-15 | 1998-01-06 | Hewlett-Packard Company | Zymbolic history management system |
| US5946490A (en) * | 1996-03-22 | 1999-08-31 | Northeastern University | Automata-theoretic approach compiler for adaptive software |
| US6366930B1 (en) * | 1996-04-12 | 2002-04-02 | Computer Associates Think, Inc. | Intelligent data inventory & asset management systems method and apparatus |
| US5890176A (en) * | 1996-04-24 | 1999-03-30 | International Business Machines Corp. | Object-oriented document version tracking method and apparatus |
| US5960444A (en) * | 1996-07-01 | 1999-09-28 | Sun Microsystems, Inc. | Software tool for indexing document made from plurality of smaller documents created using different versions of word processing software |
| US5881292A (en) * | 1996-09-26 | 1999-03-09 | Microsoft Corporation | Dynamic versioning system for multiple users of multi-module software system |
| US5950209A (en) * | 1996-10-02 | 1999-09-07 | Alcatel Usa Sourcing, L.P. | Software release control system and method |
| US5960196A (en) * | 1996-12-18 | 1999-09-28 | Alcatel Usa Sourcing, L.P. | Software release metric reporting system and method |
| US5903897A (en) * | 1996-12-18 | 1999-05-11 | Alcatel Usa Sourcing, L.P. | Software documentation release control system |
| US7330870B1 (en) * | 1997-02-11 | 2008-02-12 | International Business Machines Corporation | Streaming computer system and method with multi-version protocol compatibility |
| US5946700A (en) * | 1997-10-31 | 1999-08-31 | Oracle Corporation | Method and apparatus for preserving non-current information that can be overwritten in a computer file |
| US6321258B1 (en) * | 1997-12-11 | 2001-11-20 | Hewlett-Packard Company | Administration of networked peripherals using particular file system |
| US6195795B1 (en) | 1997-12-19 | 2001-02-27 | Alcatel Usa Sourcing, L.P. | Apparatus and method for automatic software release notification |
| US7071934B1 (en) * | 1998-03-20 | 2006-07-04 | International Business Machines Corp. | Method and apparatus for visually-oriented navigation of compared object versions |
| US7013305B2 (en) | 2001-10-01 | 2006-03-14 | International Business Machines Corporation | Managing the state of coupling facility structures, detecting by one or more systems coupled to the coupling facility, the suspended state of the duplexed command, detecting being independent of message exchange |
| US6163811A (en) * | 1998-10-21 | 2000-12-19 | Wildseed, Limited | Token based source file compression/decompression and its application |
| US6532588B1 (en) * | 1998-10-21 | 2003-03-11 | Xoucin, Inc. | User centric program product distribution |
| US6195796B1 (en) * | 1998-10-21 | 2001-02-27 | Wildseed, Ltd. | User centric source control |
| US6256773B1 (en) * | 1999-08-31 | 2001-07-03 | Accenture Llp | System, method and article of manufacture for configuration management in a development architecture framework |
| US7139999B2 (en) | 1999-08-31 | 2006-11-21 | Accenture Llp | Development architecture framework |
| US6662357B1 (en) | 1999-08-31 | 2003-12-09 | Accenture Llp | Managing information in an integrated development architecture framework |
| US7146608B1 (en) | 1999-09-28 | 2006-12-05 | Cisco Technology, Inc. | Method and system for a software release process |
| US6490596B1 (en) * | 1999-11-09 | 2002-12-03 | International Business Machines Corporation | Method of transmitting streamlined data updates by selectively omitting unchanged data parts |
| GB9930124D0 (en) | 1999-12-21 | 2000-02-09 | Ibm | File system for a computer and method of synchronising sets of files |
| US6931592B1 (en) * | 2000-05-22 | 2005-08-16 | Microsoft Corporation | Reviewing and merging electronic documents |
| US20050010652A1 (en) * | 2000-06-22 | 2005-01-13 | Ideogram Design S.A.R.L. | Process and device for selective download of data based on index file transmitted from a central server |
| AU2001296576A1 (en) * | 2000-10-04 | 2002-04-15 | Siemens Energy And Automation, Inc. | Manufacturing system software version management |
| US6754717B1 (en) * | 2000-10-23 | 2004-06-22 | International Business Machines Corporation | Establishing compatibility of messages for communicating between processing entities with continuous availability |
| US7131112B1 (en) * | 2000-11-21 | 2006-10-31 | Microsoft Corporation | Managing code changes for software development |
| US7251752B2 (en) | 2001-10-01 | 2007-07-31 | Adams Phillip M | Computerized product improvement apparatus and method |
| US20030105912A1 (en) * | 2001-11-30 | 2003-06-05 | Noren Gregory T. | Space efficient backup technique in a storage system |
| US7136916B2 (en) * | 2002-03-08 | 2006-11-14 | Siemens Aktiengesellschaft | Method for event management |
| US7219344B2 (en) * | 2002-04-30 | 2007-05-15 | Accenture Global Services Gmbh | Method and apparatus for deploying programs and computing platforms to selected computers |
| US7337388B2 (en) * | 2003-01-02 | 2008-02-26 | Microsoft Corporation | Tool-based iterative document management |
| US7055008B2 (en) | 2003-01-22 | 2006-05-30 | Falconstor Software, Inc. | System and method for backing up data |
| US20040260780A1 (en) * | 2003-06-18 | 2004-12-23 | International Business Machines Corporation | System, method, and program product for managing messages |
| US20050076040A1 (en) * | 2003-10-02 | 2005-04-07 | Sherburne Timothy J. | Communications system version processing |
| US7254593B2 (en) * | 2004-01-16 | 2007-08-07 | International Business Machines Corporation | System and method for tracking annotations of data sources |
| KR100582896B1 (en) * | 2004-01-28 | 2006-05-24 | 삼성전자주식회사 | Auto version managing system and method for software |
| US7562357B2 (en) * | 2004-03-08 | 2009-07-14 | Microsoft Corporation | Relational database schema version management |
| US7821516B2 (en) * | 2004-05-17 | 2010-10-26 | Pixar | Automatic pre-render pinning of change isolated assets methods and apparatus |
| US20060064634A1 (en) * | 2004-09-17 | 2006-03-23 | International Business Machines Corporation | Editing multiple file versions |
| US8775823B2 (en) | 2006-12-29 | 2014-07-08 | Commvault Systems, Inc. | System and method for encrypting secondary copies of data |
| JP2006260314A (en) * | 2005-03-18 | 2006-09-28 | Dainippon Screen Mfg Co Ltd | Application software configuration management device, application software configuration management method and program |
| US7716182B2 (en) * | 2005-05-25 | 2010-05-11 | Dassault Systemes Enovia Corp. | Version-controlled cached data store |
| JP4659537B2 (en) * | 2005-07-05 | 2011-03-30 | 株式会社日立製作所 | File providing method, storage device, and file providing program |
| US8868524B2 (en) * | 2005-08-25 | 2014-10-21 | International Business Machines Corporation | Floating merge selection viewer |
| US8595628B2 (en) * | 2005-11-29 | 2013-11-26 | International Business Machines Corporation | Method and system for reviewing text files using distributable review data packets |
| US7818262B2 (en) * | 2005-12-19 | 2010-10-19 | Commvault Systems, Inc. | System and method for providing a flexible licensing system for digital content |
| US8572330B2 (en) | 2005-12-19 | 2013-10-29 | Commvault Systems, Inc. | Systems and methods for granular resource management in a storage network |
| US20070150433A1 (en) * | 2005-12-22 | 2007-06-28 | Mediatek Inc. | Method for managing file in version control system |
| US8548947B2 (en) * | 2006-04-28 | 2013-10-01 | Hewlett-Packard Development Company, L.P. | Systems and methods for file maintenance |
| US8370442B2 (en) | 2008-08-29 | 2013-02-05 | Commvault Systems, Inc. | Method and system for leveraging identified changes to a mail server |
| US8677091B2 (en) | 2006-12-18 | 2014-03-18 | Commvault Systems, Inc. | Writing data and storage system specific metadata to network attached storage device |
| US7603393B1 (en) * | 2007-04-02 | 2009-10-13 | Juniper Networks, Inc. | Software merging utility |
| US20090158250A1 (en) * | 2007-12-18 | 2009-06-18 | International Business Machines Corporation | Systems, methods and computer program products for operation history management for hpc programs optimization |
| US8769048B2 (en) | 2008-06-18 | 2014-07-01 | Commvault Systems, Inc. | Data protection scheduling, such as providing a flexible backup window in a data protection system |
| US8484162B2 (en) | 2008-06-24 | 2013-07-09 | Commvault Systems, Inc. | De-duplication systems and methods for application-specific data |
| US8335776B2 (en) * | 2008-07-02 | 2012-12-18 | Commvault Systems, Inc. | Distributed indexing system for data storage |
| US8307177B2 (en) | 2008-09-05 | 2012-11-06 | Commvault Systems, Inc. | Systems and methods for management of virtualization data |
| US8307010B2 (en) * | 2008-09-26 | 2012-11-06 | Microsoft Corporation | Data feature tracking through hierarchical node sets |
| US8943183B2 (en) | 2008-12-10 | 2015-01-27 | Commvault Systems, Inc. | Decoupled installation of data management systems |
| US8624898B1 (en) | 2009-03-09 | 2014-01-07 | Pixar | Typed dependency graphs |
| US8209307B2 (en) | 2009-03-31 | 2012-06-26 | Commvault Systems, Inc. | Systems and methods for data migration in a clustered file system |
| US8315981B2 (en) * | 2009-03-31 | 2012-11-20 | Commvault Systems, Inc. | Data mining systems and methods for heterogeneous data sources |
| CN101551736B (en) * | 2009-05-20 | 2010-11-03 | 杭州华三通信技术有限公司 | Cache management device and method based on address pointer linked list |
| US8930306B1 (en) | 2009-07-08 | 2015-01-06 | Commvault Systems, Inc. | Synchronized data deduplication |
| US8990249B1 (en) * | 2009-07-20 | 2015-03-24 | Hrl Laboratories, Llc | Revision control server with self-hosting multi-level access controls and user notifications |
| US8572719B2 (en) | 2010-05-28 | 2013-10-29 | Commvault Systems, Inc. | Firewall proxy systems and methods in a backup environment |
| US11449394B2 (en) | 2010-06-04 | 2022-09-20 | Commvault Systems, Inc. | Failover systems and methods for performing backup operations, including heterogeneous indexing and load balancing of backup and indexing resources |
| US8504526B2 (en) | 2010-06-04 | 2013-08-06 | Commvault Systems, Inc. | Failover systems and methods for performing backup operations |
| US8495420B2 (en) | 2010-07-16 | 2013-07-23 | Commvault Systems, Inc. | Registry key federation systems and methods |
| US8504869B2 (en) | 2010-07-16 | 2013-08-06 | Commvault Systems, Inc. | Kernel swapping systems and methods for recovering a network device |
| US8364652B2 (en) | 2010-09-30 | 2013-01-29 | Commvault Systems, Inc. | Content aligned block-based deduplication |
| US8572340B2 (en) | 2010-09-30 | 2013-10-29 | Commvault Systems, Inc. | Systems and methods for retaining and using data block signatures in data protection operations |
| US9020900B2 (en) | 2010-12-14 | 2015-04-28 | Commvault Systems, Inc. | Distributed deduplicated storage system |
| US8954446B2 (en) | 2010-12-14 | 2015-02-10 | Comm Vault Systems, Inc. | Client-side repository in a networked deduplicated storage system |
| US9323466B2 (en) | 2011-04-27 | 2016-04-26 | Commvault Systems, Inc. | System and method for client policy assignment in a data storage system |
| US20130227352A1 (en) | 2012-02-24 | 2013-08-29 | Commvault Systems, Inc. | Log monitoring |
| US9292815B2 (en) | 2012-03-23 | 2016-03-22 | Commvault Systems, Inc. | Automation of data storage activities |
| US9286327B2 (en) | 2012-03-30 | 2016-03-15 | Commvault Systems, Inc. | Data storage recovery automation |
| US9189167B2 (en) | 2012-05-31 | 2015-11-17 | Commvault Systems, Inc. | Shared library in a data storage system |
| US8977672B2 (en) | 2012-06-08 | 2015-03-10 | Commvault Systems, Inc. | Intelligent scheduling for remote computers |
| US9189170B2 (en) | 2012-06-12 | 2015-11-17 | Commvault Systems, Inc. | External storage manager for a data storage cell |
| US20130339310A1 (en) | 2012-06-13 | 2013-12-19 | Commvault Systems, Inc. | Restore using a client side signature repository in a networked storage system |
| US20140025796A1 (en) | 2012-07-19 | 2014-01-23 | Commvault Systems, Inc. | Automated grouping of computing devices in a networked data storage system |
| US9275086B2 (en) | 2012-07-20 | 2016-03-01 | Commvault Systems, Inc. | Systems and methods for database archiving |
| US20140040580A1 (en) | 2012-07-31 | 2014-02-06 | Commvault Systems, Inc. | Administering a shared, on-line pool of data storage resources for performing data storage operations |
| US8938481B2 (en) | 2012-08-13 | 2015-01-20 | Commvault Systems, Inc. | Generic file level restore from a block-level secondary copy |
| US9026498B2 (en) | 2012-08-13 | 2015-05-05 | Commvault Systems, Inc. | Lightweight mounting of a secondary copy of file system data |
| US9152665B2 (en) | 2012-11-13 | 2015-10-06 | Sap Se | Labeling versioned hierarchical data |
| US9223597B2 (en) | 2012-12-21 | 2015-12-29 | Commvault Systems, Inc. | Archiving virtual machines in a data storage system |
| US9201906B2 (en) | 2012-12-21 | 2015-12-01 | Commvault Systems, Inc. | Systems and methods to perform data backup in data storage systems |
| US9747169B2 (en) | 2012-12-21 | 2017-08-29 | Commvault Systems, Inc. | Reporting using data obtained during backup of primary storage |
| US20140181047A1 (en) | 2012-12-21 | 2014-06-26 | Commvault Systems, Inc. | Systems and methods to protect deleted files |
| US20140181038A1 (en) | 2012-12-21 | 2014-06-26 | Commvault Systems, Inc. | Systems and methods to categorize unprotected virtual machines |
| US20140196039A1 (en) | 2013-01-08 | 2014-07-10 | Commvault Systems, Inc. | Virtual machine categorization system and method |
| US9760444B2 (en) | 2013-01-11 | 2017-09-12 | Commvault Systems, Inc. | Sharing of secondary storage data |
| US9633033B2 (en) | 2013-01-11 | 2017-04-25 | Commvault Systems, Inc. | High availability distributed deduplicated storage system |
| US9336226B2 (en) | 2013-01-11 | 2016-05-10 | Commvault Systems, Inc. | Criteria-based data synchronization management |
| US9804930B2 (en) | 2013-01-11 | 2017-10-31 | Commvault Systems, Inc. | Partial file restore in a data storage system |
| US9766987B2 (en) | 2013-01-11 | 2017-09-19 | Commvault Systems, Inc. | Table level database restore in a data storage system |
| US9483489B2 (en) | 2013-01-14 | 2016-11-01 | Commvault Systems, Inc. | Partial sharing of secondary storage files in a data storage system |
| US9483655B2 (en) | 2013-03-12 | 2016-11-01 | Commvault Systems, Inc. | File backup with selective encryption |
| US9405635B2 (en) | 2013-04-16 | 2016-08-02 | Commvault Systems, Inc. | Multi-source restore in an information management system |
| US9727544B2 (en) | 2013-05-06 | 2017-08-08 | Dropbox, Inc. | Animating edits to documents |
| US9483363B2 (en) | 2013-05-08 | 2016-11-01 | Commvault Systems, Inc. | Use of temporary secondary copies in failover operations |
| US9483558B2 (en) | 2013-05-29 | 2016-11-01 | Commvault Systems, Inc. | Assessing user performance in a community of users of data storage resources |
| US20150074536A1 (en) | 2013-09-12 | 2015-03-12 | Commvault Systems, Inc. | File manager integration with virtualization in an information management system, including user control and storage management of virtual machines |
| US9590886B2 (en) | 2013-11-01 | 2017-03-07 | Commvault Systems, Inc. | Systems and methods for differential health checking of an information management system |
| US9336228B2 (en) * | 2013-12-18 | 2016-05-10 | Verizon Patent And Licensing Inc. | Synchronization of program code between revision management applications utilizing different version-control architectures |
| US10169121B2 (en) | 2014-02-27 | 2019-01-01 | Commvault Systems, Inc. | Work flow management for an information management system |
| US9633026B2 (en) | 2014-03-13 | 2017-04-25 | Commvault Systems, Inc. | Systems and methods for protecting email data |
| US10380072B2 (en) | 2014-03-17 | 2019-08-13 | Commvault Systems, Inc. | Managing deletions from a deduplication database |
| US9811427B2 (en) | 2014-04-02 | 2017-11-07 | Commvault Systems, Inc. | Information management by a media agent in the absence of communications with a storage manager |
| US9274790B2 (en) * | 2014-04-30 | 2016-03-01 | Oracle International Corporation | Customization manager |
| US20160004605A1 (en) | 2014-07-01 | 2016-01-07 | Commvault Systems, Inc. | Lightweight data reconstruction based on backup data |
| US20160019317A1 (en) | 2014-07-16 | 2016-01-21 | Commvault Systems, Inc. | Volume or virtual machine level backup and generating placeholders for virtual machine files |
| US20160019117A1 (en) | 2014-07-16 | 2016-01-21 | Commvault Systems, Inc. | Creating customized bootable image for client computing device from backup copy |
| US20160019224A1 (en) | 2014-07-18 | 2016-01-21 | Commvault Systems, Inc. | File system content archiving based on third-party application archiving rules and metadata |
| US10031917B2 (en) | 2014-07-29 | 2018-07-24 | Commvault Systems, Inc. | Efficient volume-level replication of data via snapshots in an information management system |
| US9641388B2 (en) | 2014-07-29 | 2017-05-02 | Commvault Systems, Inc. | Customized deployment in information management systems |
| US10360110B2 (en) | 2014-08-06 | 2019-07-23 | Commvault Systems, Inc. | Point-in-time backups of a production application made accessible over fibre channel and/or iSCSI as data sources to a remote application by representing the backups as pseudo-disks operating apart from the production application and its host |
| US9852026B2 (en) | 2014-08-06 | 2017-12-26 | Commvault Systems, Inc. | Efficient application recovery in an information management system based on a pseudo-storage-device driver |
| US11249858B2 (en) | 2014-08-06 | 2022-02-15 | Commvault Systems, Inc. | Point-in-time backups of a production application made accessible over fibre channel and/or ISCSI as data sources to a remote application by representing the backups as pseudo-disks operating apart from the production application and its host |
| US9405928B2 (en) | 2014-09-17 | 2016-08-02 | Commvault Systems, Inc. | Deriving encryption rules based on file content |
| US9710465B2 (en) | 2014-09-22 | 2017-07-18 | Commvault Systems, Inc. | Efficiently restoring execution of a backed up virtual machine based on coordination with virtual-machine-file-relocation operations |
| US9417968B2 (en) | 2014-09-22 | 2016-08-16 | Commvault Systems, Inc. | Efficiently restoring execution of a backed up virtual machine based on coordination with virtual-machine-file-relocation operations |
| US9436555B2 (en) | 2014-09-22 | 2016-09-06 | Commvault Systems, Inc. | Efficient live-mount of a backed up virtual machine in a storage management system |
| US10204010B2 (en) | 2014-10-03 | 2019-02-12 | Commvault Systems, Inc. | Intelligent protection of off-line mail data |
| US9609058B2 (en) | 2014-10-13 | 2017-03-28 | Commvault Systems, Inc. | Storage management operations based on executable files served on demand to storage management components |
| US9575673B2 (en) | 2014-10-29 | 2017-02-21 | Commvault Systems, Inc. | Accessing a file system using tiered deduplication |
| US10776209B2 (en) | 2014-11-10 | 2020-09-15 | Commvault Systems, Inc. | Cross-platform virtual machine backup and replication |
| US9848046B2 (en) | 2014-11-13 | 2017-12-19 | Commvault Systems, Inc. | Archiving applications in information management systems |
| US9983936B2 (en) | 2014-11-20 | 2018-05-29 | Commvault Systems, Inc. | Virtual machine change block tracking |
| US20160162364A1 (en) | 2014-12-03 | 2016-06-09 | Commvault Systems, Inc. | Secondary storage pruning |
| US9632713B2 (en) | 2014-12-03 | 2017-04-25 | Commvault Systems, Inc. | Secondary storage editor |
| US9645891B2 (en) | 2014-12-04 | 2017-05-09 | Commvault Systems, Inc. | Opportunistic execution of secondary copy operations |
| US9753816B2 (en) | 2014-12-05 | 2017-09-05 | Commvault Systems, Inc. | Synchronization based on filtered browsing |
| US9600273B2 (en) * | 2014-12-16 | 2017-03-21 | Google Inc. | Efficient annotation system for distributed version control systems |
| US20160210306A1 (en) | 2015-01-15 | 2016-07-21 | Commvault Systems, Inc. | Managing structured data in a data storage system |
| US20160210044A1 (en) | 2015-01-15 | 2016-07-21 | Commvault Systems, Inc. | Intelligent hybrid drive caching |
| US9588849B2 (en) | 2015-01-20 | 2017-03-07 | Commvault Systems, Inc. | Synchronizing selected portions of data in a storage management system |
| US9952934B2 (en) | 2015-01-20 | 2018-04-24 | Commvault Systems, Inc. | Synchronizing selected portions of data in a storage management system |
| US10108687B2 (en) | 2015-01-21 | 2018-10-23 | Commvault Systems, Inc. | Database protection using block-level mapping |
| US9575804B2 (en) | 2015-03-27 | 2017-02-21 | Commvault Systems, Inc. | Job management and resource allocation |
| US9928144B2 (en) | 2015-03-30 | 2018-03-27 | Commvault Systems, Inc. | Storage management of data using an open-archive architecture, including streamlined access to primary data originally stored on network-attached storage and archived to secondary storage |
| US10339106B2 (en) | 2015-04-09 | 2019-07-02 | Commvault Systems, Inc. | Highly reusable deduplication database after disaster recovery |
| US9934265B2 (en) | 2015-04-09 | 2018-04-03 | Commvault Systems, Inc. | Management of log data |
| US9710253B2 (en) | 2015-04-16 | 2017-07-18 | Commvault Systems, Inc. | Managing a software-patch submission queue |
| US9904598B2 (en) | 2015-04-21 | 2018-02-27 | Commvault Systems, Inc. | Content-independent and database management system-independent synthetic full backup of a database based on snapshot technology |
| US9639286B2 (en) | 2015-05-14 | 2017-05-02 | Commvault Systems, Inc. | Restore of secondary data using thread pooling |
| US20160350391A1 (en) | 2015-05-26 | 2016-12-01 | Commvault Systems, Inc. | Replication using deduplicated secondary copy data |
| US10120661B2 (en) * | 2015-07-16 | 2018-11-06 | Sugarcrm Inc. | Multi-flavored software execution from a singular code base |
| US9766825B2 (en) | 2015-07-22 | 2017-09-19 | Commvault Systems, Inc. | Browse and restore for block-level backups |
| US10192065B2 (en) | 2015-08-31 | 2019-01-29 | Commvault Systems, Inc. | Automated intelligent provisioning of data storage resources in response to user requests in a data storage management system |
| EP3350728B1 (en) | 2015-09-18 | 2022-04-06 | Commvault Systems, Inc. | Data storage management operations in a secondary storage subsystem using image recognition and image-based criteria |
| US10459801B2 (en) | 2015-09-30 | 2019-10-29 | Commvault Systems, Inc. | Dynamic triggering of block-level backups based on block change thresholds and corresponding file identities using indexing in a data storage management system |
| US10353994B2 (en) | 2015-11-03 | 2019-07-16 | Commvault Systems, Inc. | Summarization of email on a client computing device based on content contribution to an email thread using classification and word frequency considerations |
| US10228962B2 (en) | 2015-12-09 | 2019-03-12 | Commvault Systems, Inc. | Live synchronization and management of virtual machines across computing and virtualization platforms and using live synchronization to support disaster recovery |
| US10387266B2 (en) | 2015-12-23 | 2019-08-20 | Commvault Systems, Inc. | Application-level live synchronization across computing platforms including synchronizing co-resident applications to disparate standby destinations and selectively synchronizing some applications and not others |
| US10592357B2 (en) | 2015-12-30 | 2020-03-17 | Commvault Systems, Inc. | Distributed file system in a distributed deduplication data storage system |
| US10684924B2 (en) | 2016-02-18 | 2020-06-16 | Commvault Systems, Inc. | Data restoration operations based on network path information |
| US10565067B2 (en) | 2016-03-09 | 2020-02-18 | Commvault Systems, Inc. | Virtual server cloud file system for virtual machine backup from cloud operations |
| US10452490B2 (en) | 2016-03-09 | 2019-10-22 | Commvault Systems, Inc. | Data management and backup of distributed storage environment |
| US10296368B2 (en) | 2016-03-09 | 2019-05-21 | Commvault Systems, Inc. | Hypervisor-independent block-level live browse for access to backed up virtual machine (VM) data and hypervisor-free file-level recovery (block-level pseudo-mount) |
| US10248174B2 (en) | 2016-05-24 | 2019-04-02 | Hedvig, Inc. | Persistent reservations for virtual disk using multiple targets |
| US10664447B2 (en) | 2016-07-12 | 2020-05-26 | Commvault Systems, Inc. | Dynamic management of expandable cache storage for multiple network shares configured in a file server |
| US10747630B2 (en) | 2016-09-30 | 2020-08-18 | Commvault Systems, Inc. | Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, including operations by a master monitor node |
| US10162528B2 (en) | 2016-10-25 | 2018-12-25 | Commvault Systems, Inc. | Targeted snapshot based on virtual machine location |
| US10210048B2 (en) | 2016-10-25 | 2019-02-19 | Commvault Systems, Inc. | Selective snapshot and backup copy operations for individual virtual machines in a shared storage |
| US11106632B2 (en) | 2016-11-16 | 2021-08-31 | Commvault Systems, Inc. | Dynamically configuring a proxy server using containerization for concurrent and/or overlapping backup, restore, and/or test operations |
| US10678758B2 (en) | 2016-11-21 | 2020-06-09 | Commvault Systems, Inc. | Cross-platform virtual machine data and memory backup and replication |
| KR20180072436A (en) * | 2016-12-21 | 2018-06-29 | 엘에스산전 주식회사 | Apparatus for providing program |
| US10740193B2 (en) | 2017-02-27 | 2020-08-11 | Commvault Systems, Inc. | Hypervisor-independent reference copies of virtual machine payload data based on block-level pseudo-mount |
| US20180276085A1 (en) | 2017-03-24 | 2018-09-27 | Commvault Systems, Inc. | Virtual machine recovery point generation |
| US10613939B2 (en) | 2017-03-28 | 2020-04-07 | Commvault Systems, Inc. | Backup index generation process |
| US10599527B2 (en) | 2017-03-29 | 2020-03-24 | Commvault Systems, Inc. | Information management cell health monitoring system |
| US10387073B2 (en) | 2017-03-29 | 2019-08-20 | Commvault Systems, Inc. | External dynamic virtual machine synchronization |
| US10949398B2 (en) | 2017-03-29 | 2021-03-16 | Commvault Systems, Inc. | Synchronization operations for network-accessible folders |
| KR20180119857A (en) * | 2017-04-26 | 2018-11-05 | 현대자동차주식회사 | Method and apparatus for software change impact analysis |
| US10664352B2 (en) | 2017-06-14 | 2020-05-26 | Commvault Systems, Inc. | Live browsing of backed up data residing on cloned disks |
| US10846266B2 (en) | 2017-09-14 | 2020-11-24 | Commvault Systems, Inc. | Distributed architecture for content indexing emails |
| US11263088B2 (en) | 2017-09-14 | 2022-03-01 | Commvault Systems, Inc. | Distributed architecture for tracking content indexing |
| US10846180B2 (en) | 2017-09-14 | 2020-11-24 | Commvault Systems, Inc. | Distributed framework for task splitting and task assignments in a content indexing system |
| US11036592B2 (en) | 2017-09-14 | 2021-06-15 | Commvault Systems, Inc. | Distributed content indexing architecture with separately stored file previews |
| US11086834B2 (en) | 2017-09-14 | 2021-08-10 | Commvault Systems, Inc. | Distributed framework for data proximity-based task splitting in a content indexing system |
| US10108533B1 (en) | 2017-09-25 | 2018-10-23 | Bank Of America Corporation | Enterprise framework for efficient software deployment |
| US10635546B2 (en) | 2017-12-07 | 2020-04-28 | Commvault Systems, Inc. | Synthesizing a restore image from one or more secondary copies to facilitate data restore operations to a file server |
| US10740300B1 (en) | 2017-12-07 | 2020-08-11 | Commvault Systems, Inc. | Synchronization of metadata in a distributed storage system |
| US10742735B2 (en) | 2017-12-12 | 2020-08-11 | Commvault Systems, Inc. | Enhanced network attached storage (NAS) services interfacing to cloud storage |
| US10503496B2 (en) | 2018-02-02 | 2019-12-10 | Bank Of America Corporation | Smart tool for enterprise-wide version control of codes during software integration and deployment |
| US10467121B2 (en) | 2018-02-02 | 2019-11-05 | Bank Of America Corporation | Smart tool for enterprise-wide software integration and deployment |
| US10592145B2 (en) | 2018-02-14 | 2020-03-17 | Commvault Systems, Inc. | Machine learning-based data object storage |
| US10474556B2 (en) | 2018-02-20 | 2019-11-12 | Bank Of America Corporation | Multiple ruleset version scanning, warning and correction tool |
| US10848468B1 (en) | 2018-03-05 | 2020-11-24 | Commvault Systems, Inc. | In-flight data encryption/decryption for a distributed storage platform |
| US10877928B2 (en) | 2018-03-07 | 2020-12-29 | Commvault Systems, Inc. | Using utilities injected into cloud-based virtual machines for speeding up virtual machine backup operations |
| US10761942B2 (en) | 2018-03-12 | 2020-09-01 | Commvault Systems, Inc. | Recovery point objective (RPO) driven backup scheduling in a data storage management system using an enhanced data agent |
| US11321183B2 (en) | 2018-05-02 | 2022-05-03 | Commvault Systems, Inc. | Multi-tiered backup indexing |
| US10673943B2 (en) | 2018-05-02 | 2020-06-02 | Commvault Systems, Inc. | Network storage backup using distributed media agents |
| US11249863B2 (en) | 2018-05-02 | 2022-02-15 | Commvault Systems, Inc. | Backup-based media agent configuration |
| US10893103B2 (en) | 2018-07-25 | 2021-01-12 | Commvault Systems, Inc. | Distributed and scalable storage management using a storage-microservices server |
| US10891304B2 (en) | 2018-07-25 | 2021-01-12 | Commvault Systems, Inc. | Distributed and scalable client-based storage management |
| US11016696B2 (en) | 2018-09-14 | 2021-05-25 | Commvault Systems, Inc. | Redundant distributed data storage system |
| US11010258B2 (en) | 2018-11-27 | 2021-05-18 | Commvault Systems, Inc. | Generating backup copies through interoperability between components of a data storage management system and appliances for data storage and deduplication |
| US11200124B2 (en) | 2018-12-06 | 2021-12-14 | Commvault Systems, Inc. | Assigning backup resources based on failover of partnered data storage servers in a data storage management system |
| US10860443B2 (en) | 2018-12-10 | 2020-12-08 | Commvault Systems, Inc. | Evaluation and reporting of recovery readiness in a data storage management system |
| US11698727B2 (en) | 2018-12-14 | 2023-07-11 | Commvault Systems, Inc. | Performing secondary copy operations based on deduplication performance |
| US11012508B2 (en) | 2018-12-14 | 2021-05-18 | Commvault Systems, Inc. | Region-based distributed information management system |
| US10922291B2 (en) * | 2018-12-21 | 2021-02-16 | Palantir Technologies Inc. | Data pipeline branching |
| US11347707B2 (en) | 2019-01-22 | 2022-05-31 | Commvault Systems, Inc. | File indexing for virtual machine backups based on using live browse features |
| US10872069B2 (en) | 2019-01-22 | 2020-12-22 | Commvault Systems, Inc. | File indexing for virtual machine backups in a data storage management system |
| US10768971B2 (en) | 2019-01-30 | 2020-09-08 | Commvault Systems, Inc. | Cross-hypervisor live mount of backed up virtual machine data |
| US10996974B2 (en) | 2019-01-30 | 2021-05-04 | Commvault Systems, Inc. | Cross-hypervisor live mount of backed up virtual machine data, including management of cache storage for virtual machine data |
| US11126365B2 (en) | 2019-03-11 | 2021-09-21 | Commvault Systems, Inc. | Skipping data backed up in prior backup operations |
| US11269732B2 (en) | 2019-03-12 | 2022-03-08 | Commvault Systems, Inc. | Managing structured data in a data storage system |
| US11321184B2 (en) | 2019-03-26 | 2022-05-03 | Commvault Systems, Inc. | Streamlined secondary copy operations for data stored on shared file storage |
| US20200327017A1 (en) | 2019-04-10 | 2020-10-15 | Commvault Systems, Inc. | Restore using deduplicated secondary copy data |
| US11100064B2 (en) | 2019-04-30 | 2021-08-24 | Commvault Systems, Inc. | Automated log-based remediation of an information management system |
| US11442623B2 (en) | 2019-05-02 | 2022-09-13 | Commvault Systems, Inc. | Faster browse of secondary copies of block-level data volumes |
| US11463264B2 (en) | 2019-05-08 | 2022-10-04 | Commvault Systems, Inc. | Use of data block signatures for monitoring in an information management system |
| US20210037112A1 (en) | 2019-07-29 | 2021-02-04 | Commvault Systems, Inc. | Data storage system with rapid restore capability |
| US11263173B2 (en) | 2019-07-30 | 2022-03-01 | Commvault Systems, Inc. | Transaction log index generation in an enterprise backup system |
| US11513922B2 (en) | 2019-08-14 | 2022-11-29 | Commvault Systems, Inc. | Systems and methods for change block tracking for backing up changed data |
| US11237935B2 (en) | 2019-09-11 | 2022-02-01 | Commvault Systems, Inc. | Anomaly detection in data protection operations |
| US11218450B2 (en) | 2019-09-11 | 2022-01-04 | Commvault Systems, Inc. | Data protection component scaling in a cloud-based data storage system |
| US11256673B2 (en) | 2019-09-11 | 2022-02-22 | Commvault Systems, Inc. | Anomaly detection in deduplication pruning operations |
| US11663178B2 (en) | 2019-11-04 | 2023-05-30 | Commvault Systems, Inc. | Efficient implementation of multiple deduplication databases in a heterogeneous data storage system |
| US20210173811A1 (en) | 2019-12-04 | 2021-06-10 | Commvault Systems, Inc. | Optimizing the restoration of deduplicated data stored in multi-node replicated file systems |
| US11237924B2 (en) | 2019-12-11 | 2022-02-01 | Commvault Systems, Inc. | Dynamic resizing and re-distribution of destination data storage resources for bare metal restore operations in a data storage management system |
| US11223535B2 (en) | 2019-12-31 | 2022-01-11 | Commvault Systems, Inc. | Smart network topology systems and methods |
| US11467753B2 (en) | 2020-02-14 | 2022-10-11 | Commvault Systems, Inc. | On-demand restore of virtual machine data |
| US11005935B1 (en) | 2020-03-10 | 2021-05-11 | Commvault Systems, Inc. | Using multiple streams with network data management protocol to improve performance and granularity of backup and restore operations from/to a file server |
| US11334442B2 (en) | 2020-03-10 | 2022-05-17 | Commvault Systems, Inc. | Management database long-term archiving to a recovery manager |
| US11442768B2 (en) | 2020-03-12 | 2022-09-13 | Commvault Systems, Inc. | Cross-hypervisor live recovery of virtual machines |
| US11099956B1 (en) | 2020-03-26 | 2021-08-24 | Commvault Systems, Inc. | Snapshot-based disaster recovery orchestration of virtual machine failover and failback operations |
| US11748143B2 (en) | 2020-05-15 | 2023-09-05 | Commvault Systems, Inc. | Live mount of virtual machines in a public cloud computing environment |
| US11687424B2 (en) | 2020-05-28 | 2023-06-27 | Commvault Systems, Inc. | Automated media agent state management |
| US11294664B2 (en) | 2020-06-05 | 2022-04-05 | CrossVista, Inc. | Version control system |
| US11354118B2 (en) | 2020-06-05 | 2022-06-07 | Cross Vista, Inc. | Version control system |
| US11327663B2 (en) | 2020-06-09 | 2022-05-10 | Commvault Systems, Inc. | Ensuring the integrity of data storage volumes used in block-level live synchronization operations in a data storage management system |
| US11537959B2 (en) | 2020-06-16 | 2022-12-27 | Commvault Systems, Inc. | Dynamic computing progress tracker |
| US11487468B2 (en) | 2020-07-17 | 2022-11-01 | Commvault Systems, Inc. | Healing failed erasure-coded write attempts in a distributed data storage system configured with fewer storage nodes than data plus parity fragments |
| US11494417B2 (en) | 2020-08-07 | 2022-11-08 | Commvault Systems, Inc. | Automated email classification in an information management system |
| US11500566B2 (en) | 2020-08-25 | 2022-11-15 | Commvault Systems, Inc. | Cloud-based distributed data storage system using block-level deduplication based on backup frequencies of incoming backup copies |
| US11108861B1 (en) | 2020-08-26 | 2021-08-31 | Commvault Systems, Inc. | System for managing multiple information management cells |
| US11570243B2 (en) | 2020-09-22 | 2023-01-31 | Commvault Systems, Inc. | Decommissioning, re-commissioning, and commissioning new metadata nodes in a working distributed data storage system |
| US11789830B2 (en) | 2020-09-22 | 2023-10-17 | Commvault Systems, Inc. | Anti-entropy-based metadata recovery in a strongly consistent distributed data storage system |
| US11656951B2 (en) | 2020-10-28 | 2023-05-23 | Commvault Systems, Inc. | Data loss vulnerability detection |
| US11474753B2 (en) | 2020-10-30 | 2022-10-18 | Commvault Systems, Inc. | Systems and methods for backing up to a virtual tape library |
| US11687523B2 (en) | 2020-11-25 | 2023-06-27 | Salesforce, Inc. | System and method for efficiently transferring data for offline use |
| US11675800B2 (en) * | 2020-11-30 | 2023-06-13 | Salesforce, Inc. | Version control and execution on a mobile device |
| US11323513B1 (en) | 2021-01-22 | 2022-05-03 | Commvault Systems, Inc. | Geo-location-based data replication |
| US11645175B2 (en) | 2021-02-12 | 2023-05-09 | Commvault Systems, Inc. | Automatic failover of a storage manager |
| US11574050B2 (en) | 2021-03-12 | 2023-02-07 | Commvault Systems, Inc. | Media agent hardening against ransomware attacks |
| US11561978B2 (en) | 2021-06-29 | 2023-01-24 | Commvault Systems, Inc. | Intelligent cache management for mounted snapshots based on a behavior model |
| US11615147B2 (en) | 2021-08-23 | 2023-03-28 | Commvault Systems, Inc. | Mobile storage manager control application for managing a storage manager of an information management system |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4558413A (en) * | 1983-11-21 | 1985-12-10 | Xerox Corporation | Software version management system |
| EP0230616A3 (en) * | 1986-01-21 | 1991-10-23 | International Business Machines Corporation | Library management system |
| JP2566220B2 (en) * | 1986-01-27 | 1996-12-25 | キヤノン株式会社 | Information processing device |
-
1988
- 1988-04-26 US US07/183,190 patent/US4912637A/en not_active Expired - Lifetime
-
1989
- 1989-04-21 JP JP1103317A patent/JPH0228831A/en active Pending
- 1989-04-24 DE DE68925746T patent/DE68925746T2/en not_active Expired - Fee Related
- 1989-04-24 AU AU33371/89A patent/AU615536B2/en not_active Ceased
- 1989-04-24 EP EP89304043A patent/EP0339901B1/en not_active Expired - Lifetime
- 1989-04-25 CA CA000597671A patent/CA1316262C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP0339901B1 (en) | 1996-02-28 |
| EP0339901A2 (en) | 1989-11-02 |
| JPH0228831A (en) | 1990-01-30 |
| AU615536B2 (en) | 1991-10-03 |
| DE68925746T2 (en) | 1997-02-06 |
| EP0339901A3 (en) | 1991-10-09 |
| AU3337189A (en) | 1989-11-02 |
| DE68925746D1 (en) | 1996-04-04 |
| US4912637A (en) | 1990-03-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA1316262C (en) | Version management tool | |
| US6098072A (en) | Source code files in a file directory system having multiple hierarchies representing contextual views | |
| US5623661A (en) | System for and method of providing delta-versioning of the contents of PCTE file objects | |
| US5418942A (en) | System and method for storing and managing information | |
| Goldstein et al. | A layered approach to software design | |
| US5551028A (en) | Design data management system and associated method | |
| US6826604B2 (en) | Input/output device information management system for multi-computer system | |
| US7069547B2 (en) | Method, system, and program for utilizing impact analysis metadata of program statements in a development environment | |
| US7194475B2 (en) | Method, system, and program for performing an impact analysis of program statements in at least one source code file | |
| US5734899A (en) | Device for managing data in a version | |
| Tryon et al. | The BC TRY computer system of cluster and factor analysis | |
| US4809170A (en) | Computer device for aiding in the development of software system | |
| US20030212718A1 (en) | Revision control for database of evolved design | |
| US5740408A (en) | Method for automated software application testing | |
| EP0614150A2 (en) | Backup, restoration, migration systems of a database | |
| JPH0652531B2 (en) | Relay database management system | |
| JPH11143755A (en) | Method for copying and sharing hierarchical configuration information | |
| KR20010103603A (en) | Impact analysis of a model | |
| US4833597A (en) | Dictionary/directory management method in database system | |
| US5062039A (en) | Sharing of workspaces in interactive processing using workspace name tables for linking of workspaces | |
| US5781905A (en) | Program generating method combining data item part with database manipulation part | |
| CN100501737C (en) | Database scheme for content managed data and its setting method and system | |
| US5379407A (en) | Error handling in a state-free system | |
| EP0649543B1 (en) | Method and apparatus for facilitating user generation of decision functions | |
| CA1301366C (en) | Interactive error handling means in database management |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MKLA | Lapsed |