JPH07302194A - Managing method for version of module group - Google Patents

Abstract

PURPOSE:To provide the management method for version of the module group using a new version for a module not to be, returned when an old module group is reproduced. CONSTITUTION:When a module (1) is updated and modules (2 and others) effected by the update of the module 1 are also updated, a data base 13 manages the updated module name and a recent version of said module through cross- referencing in the unit of the module groups (1, 2 and others) and an inter- module cross reference table 14 manages information of dependence of each module on other modules. When the module name and the version of said module are designated, the version management information database 13 and the inter-module cross reference table 14 are referenced to adopt modules of new version in a range to be matched as to other modules than the module in the module group including the module.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a version management method of a module group consisting of a plurality of modules, that is, one unit in which a program created in a large project is functionally divided. The present invention relates to a module group version management method suitable for supporting the development of a task of a group of modules of a whole project in a distributed development or a collaborative development by a large number of people, which needs to maintain consistency between frequently updated modules.

[0002]

2. Description of the Related Art In large-scale software development,
In many cases, programs are created by dividing, and by this division, different creators can share and reduce the creation time, and a programming language suitable for the processing contents of each program part after the division can be created. There is an advantage that it can be created using. In such a case, the target program is created by converting each source program into a machine language program and then combining them. In addition, each source program is individually modified / changed as needed,
The revisions will be made sequentially, and the version number of the target program will also be updated according to the change of each source program. Under such circumstances, conventionally, for example, program editing has been performed by the method disclosed in Japanese Patent Laid-Open No. 5-61657. In this method, the target program is created by translating and combining the source programs, and each version of the source program is stored in the source file, and only the latest version of the target program is stored in the object file. Each edition number of the target program, and the edition management section having a version number management table in which the version number of each source program constituting the target program of the version number is associated and inputted, and this edition management section, When the old version of the target program is specified, the version number of each source program corresponding to this old version is searched from the above version management table, and then the source version of the version searched above is searched from the above source file. It is configured to extract each program, expand it into a work area, and modify / change each of these expanded source programs. Than it is.

[0003]

In the conventional general techniques including the above-mentioned conventional technique, the version management of each source program is managed as a program in which each source program is integrated, or each other source program is managed. Version management was performed without associating with the program. That is, in the automatic program search method and the like, the module (source program) is updated so as to obtain consistency, but the information is not managed and reproduction of the old version is not considered.
As a result, modules that do not need to be restored when reproducing the old version may be restored to the old version. Further, when searching for a group of modules that can be matched, it takes time and human error occurs when searching manually. Further, when the backup at the time of matching is used, there is a problem that the intervals are coarse and a large amount of memory is required. The present invention has been made in view of the above circumstances, and an object of the present invention is to solve a problem as described above in the related art and to provide a newer module that does not need to be returned when the old module group is reproduced. It is to provide a version management method for a group of modules that uses a version.

[0004]

The above objects of the present invention are as follows:
A version management method for a module group in an information processing device having a computer and an input / output device, comprising:
When (module 1) is updated, the module 1
When the module 2 and the like affected by the update of the module are also updated, the updated module name and the latest version number of the module are associated with each other, and the version management for managing these module groups (module 1, 2, etc.) as a unit It has an information database and an inter-module correspondence table that manages information on the dependency relationship of each module with other modules, and when the module name and the version number of the module are specified, the version management information database and the inter-module correspondence With reference to the table, regarding the modules other than the modules in the module group including the module, a module group version management method characterized by collecting a newer version module within the range where the consistency can be obtained. To be achieved.

[0005]

In the module group version management method according to the present invention, when a certain module (1) is updated, an affected module 2 and an inter-module correspondence table that manages other names are held and updated. The version management information database that manages the information of the module and the module that is affected and updated as a history is held, and if the name and version number of a certain module are specified, the newer version will be created for the modules other than the module. A module group that can be matched is calculated on the assumption that is selected. This allows
With respect to the modules other than the relevant module such as the update target, it is possible to obtain the effect that a newer version can be used. Also, by visually notifying the person in charge of development of the version management information of the module group registered in the version management information database described above, it is possible to notify the programmer of the history information, and when the programmer uses this function. There is also an effect that it can be used to support.

[0006]

Embodiments of the present invention will now be described in detail with reference to the drawings. FIG. 1 is a system configuration diagram for executing a module group version management method according to an embodiment of the present invention. In FIG. 1, reference numeral 10 is a workstation developed by the project participants. Reference numeral 11 is also a workstation developed by the project participants, but is different from the workstation 10 in that the shared directory 12 is provided. Reference numeral 12 is a place for registering the latest version of the current module, and is a place for executing the processing according to the present embodiment. 13 is a module to be updated and a module affected by the update of the module and updated (hereinafter referred to as “update module group”) as one unit,
It is a version management information database managed as a history. Reference numeral 14 denotes an inter-module correspondence table storage unit that manages information on the dependency relationship of each module.

Next, an embodiment will be described in detail with reference to FIGS. 2 to 7. In FIG. 2, the shared directory 1
Module A, which is one of the modules registered in No. 2, is updated (step 20). In response to this, a module update request is sent to the person in charge of the module affected by the update of the module A (hereinafter referred to as “affected module”) based on the information in the module correspondence table (see FIG. 6) (step twenty one). Figure 6 shows the module correspondence table.
An example will be described. In FIG. 6, the module names registered in the shared directory 12 are arranged in a line indicated by 60. In the table indicated by 61, module names affected by updating of 60 modules are described. Further, a column 62 has a module name affected by the module A, a column 63 has a module name affected by the module B, a column 64 has a module name affected by the module C, and a column 65 has a module name. The module names affected by D are listed respectively.

In step 21 in FIG. 2, if all the affected modules have not been updated (step 22) in response to the update request sent to the person in charge of development, the affected modules and module A are not updated yet. (Step 23). All impact modules updated (step 22)
If so, version management processing is performed on the updated module group (step 24). The version management process of the update module group will be described with reference to FIG. In FIG.
When the module is updated, each update module is individually version controlled (step 40). The latest version number of the update module when the version is managed is sent to the version management information database (step 41). In the version management information database 42,
The version number of the update module group is managed as a history (step 43).

Next, the operation of this embodiment will be described with reference to FIG. In FIG. 3, first, history information for each update module group arranged in order in the version management information database is displayed on the screen (step 30). The management status in the version management information database here will be described based on an example of FIG. In FIG. 5, 50 is an item number added each time registration is performed. Reference numeral 51 is a version management status of the module A. Reference numeral 52 denotes the version management status of the module B. Reference numeral 53 indicates the version management status of the module C. Reference numeral 54 represents the version management status of the module D. In the version management information database, only the version numbers of the updated module group are registered according to the item number 50, so that the version numbers of the modules not updated at that time are not registered. The gaps in the table of Figure 5 indicate that the module was not updated then.

Next, a request for returning the module A to the version number a2 is received (step 31). In response to this request, update information from the history information a4 to a2 of the version management information database is acquired (step 32). Based on the acquired update information, the module group matching the version of a2 of the module A is collected for modules other than A (step 33). The difference between the module a2 according to this method and the module a2 according to the conventional method will be described with reference to FIG. First, the conventional method 70 shown in FIG. 7A shows a method of sequentially registering and managing when the consistency is obtained by backup or the like.

The point shown in FIG. 7A is as follows. First, when the module C is updated from the state shown in item No. 1, the module A is updated accordingly (see FIG. 6). Next, when the module D is updated from the state shown in item No. 2, the modules B and C are updated accordingly. Further, when the module B is updated from the state shown in item No. 3, the module D is updated accordingly. Similarly, when the module C is updated from the state shown in item No. 4, the module A is updated accordingly, and when the module A is updated from the state shown in item No. 5, the modules B and D are changed accordingly. When the module B is updated and the module B is updated from the state shown in No. 6, the module D is updated accordingly. In the conventional method, the backup in each of these states is taken point by point.

On the other hand, the method 71 according to the present invention shown in FIG. 7B calculates the module group to be obtained by paying attention to the target module from the latest version without using the backup information. It is a thing. In both figures, 7
2 is an item number added each time it is registered, and here is the version number of the module group. Further, 73 indicates the version management status of the module A, 74 indicates the version management status of the module B, 75 indicates the version management status of the module C, and 76 indicates the version management status of the module D. In the conventional method, a
When 2 is reproduced, a2, b1, c2, d1 are simply obtained from the backup as shown in item 2. On the other hand, in the method according to the present invention shown in FIG.
2, b5, c3, d4 (shown in item No. 2 of 77) can be reproduced.

The difference between the method according to the present invention and the conventional method is that the conventional method is viewed from the old version in order, whereas the present method is viewed from the new version. That is, in the method according to the present invention, as shown in FIG.
When the module of interest (module A in this case) is updated, the update status of the corresponding other module is tabulated, and based on this, a2 of module A is updated.
The module group that is consistent with the version of is requested. Here, when looking from the new version in order, if a module that has a relationship of update with the target module (module A) has a relationship with the target module again, the module with that relationship is first The version number is one less than the version number when it was related to the target module.

This will be described with reference to the example of FIG.
The version numbers of the module C in the column are item numbers 6, 5 and 2, that is, C4, C4 and C3 for the modules A4, a3 and a2, respectively. Updates that are not related to the target module are ignored. In the example of FIG. 7B, the version number of the module D in the 76th column is the item number 6, 5,
This corresponds to the fact that all are d4 for 2, and the item numbers 7, 4, and 3 in the table are blank. According to the module group version management method described in the above embodiment, when reproducing the old module group, it is possible to use a newer version of the module other than the corresponding module such as the update target. can get. It is needless to say that the above embodiment shows one example of the present invention, and the present invention should not be limited to this.

[0015]

As described above in detail, according to the present invention, a module group version management method is used in which a newer version is used for a module that does not need to be returned when the old module group is reproduced. It has a remarkable effect that it can be realized. More specifically, the following effects can be obtained. (1) The version management information database manages versions with the update module and the affected module as one unit, while the inter-module correspondence table storage section manages the module name affected by the update of a certain module. So when you revert one module back to the old version to make it consistent with other modules, it will collect newer versions of the modules, except for some modules. (2) In the version management information database, version management is performed with the update module and the module affected by the update as one unit, so the module manager version management information is visually taught to the developer.

[Brief description of drawings]

FIG. 1 is a system configuration diagram for executing a module group version management method according to an embodiment of the present invention.

FIG. 2 is a flowchart showing a precondition process for creating a situation in which a version management method for a module group according to an embodiment is executed.

FIG. 3 is a flowchart showing a processing procedure in the embodiment.

FIG. 4 is a flowchart showing a processing procedure for managing a version of an updated module.

FIG. 5 is a diagram showing an example of registered information in a version management information database.

FIG. 6 is a diagram showing an example of registered information in a module correspondence table.

FIG. 7 is a diagram showing a comparison of version management information of module groups according to a conventional method and a method according to the present invention.

[Explanation of symbols]

10, 11 workstation 12 shared directory 13 version management information database 14 module correspondence table storage unit 42 version management information database 70 module group correspondence table by conventional method 71 module group correspondence table by module group version management method according to the present invention

Claims (1)

[Claims] 1. A method of managing a version of a module group in an information processing apparatus, wherein when a module (module 1) is updated, modules affected by the update of the module 1 (module 2 etc.) are also updated. In this case, the updated module name and the latest version number of the module are associated with each other, and the version management information database that manages these module groups (modules 1, 2, etc.) as a unit, and the dependency of each module on other modules It has an inter-module correspondence table that manages relationship information,
When the module name and the version number of the module are specified, the version management information database and the inter-module correspondence table are referred to, and other modules other than the module in the module group including the module are matched. A version management method for a module group, which is characterized by collecting newer version modules within a range that can be taken.