JPH0756721A - Method for managing revision - Google Patents

Abstract

PURPOSE:To prevent the generation of confusion in the development of a source module by registering a source module in a branch group for flowing while holding its registration in an individual editing branch when the source module is turned to be in a flow enabled state to another user group. CONSTITUTION:A user executes 51 work such as the edition of a source module and registers 52 the edited source module in an individual editing branch. Whether the source module is in a flow enabled state to cooperating other users or not is judged 53 and edition and registration in the individual editing branch are repeated until becoming the flow enabled state to execute revision. When the flow enabled state is set up, the source module of the revison is registered 54 in a branch group for flowing while holding its registration in the individual editing branch at the step 52. Which branch in the branch group for flowing is to be used for registration is changed in accordance with a flow format.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software development environment for realizing a large-scale software development process in which a large number of people are involved in development, and in particular, a version that holds a plurality of source modules that make up a program in module units. A server machine having a number management original storage area and a registration mechanism for registering the revision of the source module in the version management original storage area of the server machine, and a plurality of clients jointly used by a plurality of user groups A revision management method of the source module in a program development network including a machine.

[0002]

2. Description of the Related Art A program that has a history of program development and has a new version (revision) during the development process
There is a revision management method for program and source modules to control the supply of each revision.
FIG. 6 is an explanatory diagram showing a source module configuration example of a conventional revision management method.

Referring to FIG. Version (revision) is 1.
1 to 1.2, 1.3, 1.4, branching off at 1.4, 1.4.1.1, 1.4.
It shows the case where there are some that proceed to 1.2 and some that proceed to 1.5.

Here, the A maker of version 1.4 is made by a person called A, and the B maker of version 1.4.1.2 is made by a person called B. Shows.
The revision control method for managing the transition of such a version is
As shown in the figure, log information 81, source information 82,
The difference information 83, 84, ... Of each version is used.

That is, the conventional revision control method is
By recording the registration history as difference information in one source module, an arbitrary registered source module can be acquired. In addition, at the time of registration, by specifying which difference information with the registered version is recorded,
The plates can be managed in parallel in a tree shape. The symbol information for the registered version is described in the version management source module to manage which supply the registered version is.

The following can be cited as references that describe such conventional techniques.

・ Walter F. Tichy “Design, Implementa
tion, and Evaluation of RevisionControl System ”6t
h ICSE, IEEE Sep. 1982

[0008]

When the conventional revision management method described above is applied to a development process in which a plurality of users edit source modules in parallel and distribute them among developers, the following (1), ( There is a drawback shown in 2).

(1) Since the revision management method has no relation to the distribution form, so that version management can be performed in a tree form, but in the actual development process, the revision management method is used for merely storing the history. It just stays there. Or, contrary to this case, since the revision control method is not related to the distribution form, it is only used as a means for exchanging the source module among multiple developers, and it can play the role of history management. Not in any case, resulting in confusion in source module distribution among multiple developers.

(2) In the actual development process, if the number of branches is simply increased in response to the user's request, the substream of the file will increase, and it will not be known which is the real product. Bring chaos to.

The object of the present invention is: (1) In the distribution of source modules, the source module required by the developer can be reliably referred to by only one procedure, and the history of individual editing before distribution can be managed. (2) A revision in which even if a branch for parallel editing is created as needed, the edited content can be appropriately reflected in the source modules distributed throughout, and orderly parallel editing can be performed. To provide a management method.

[0012]

The version management method of the present invention is
When registering the revision of the source module to the version management original storage area of the server machine by the registration mechanism, after individually editing the source module and registering it in the individual edit branch, the source module concerned is registered in another user group. When it becomes available for distribution, there is a step of registering in the distribution branch group while being registered in the individual edit branch.

When the source module is registered in the version management original storage area of the server machine, when a parallel edit branch is extended from the branch of the common version of the source module, the specific version in the branch of the common version is edited in parallel. Register to a branch and terminate the parallel editing branch with it, or the difference from the version tagged as the latest public version to the latest common version, and the tag indicating the latest public version Compares the difference from the version marked with the latest parallel edit version to each function, and when the edited contents do not overlap, merges the latest common version and the latest parallel edit version, and terminates the parallel edit branch. And a step of confirming the presence / absence of an unterminated parallel edit branch.

[0014]

[Function] When the source module becomes available for distribution to other user groups, it is registered in the distribution branch group while being registered in the individual edit branch, so that the source module required by the developer can be surely referenced. In addition, only the well-known source module can be distributed by the only procedure, and there is no confusion in the development of the source module.

Further, even if a branch for editing in parallel is created, the edited content is reflected in a source module that is properly distributed, so that it does not cause confusion.

[0016]

Embodiments of the present invention will now be described with reference to the drawings.

FIG. 1 is a block diagram of a program development network to which the embodiment of the revision management method of the present invention is applied, FIG. 2 is a flowchart of the procedure of the first embodiment of the revision management method of FIG. 1, and FIG. FIG. 3 is a conceptual diagram showing individual editing and distribution branches in the revision management method of FIG. 2.

The program development network to which this embodiment of the revision control method is applied comprises a server machine 1, client machines 8 ₁ and 8 ₂ and a network 16. Here, a group of persons in charge of creating a product including a plurality of source modules is called a group, and in this program development network, two groups A and B are client machines 8 ₁ ,
We are working together on program development using 8 ₂ .

The server machine 1 is a machine for managing a source module, and comprises a storage device 2, a management mechanism 3, a file sharing mechanism 6 and a communication mechanism 7. The storage device 2 is a version number management file original 4 and a work file. It is equipped with 5. The version number management file original 4 has A as a group-corresponding area.
Group areas 41A and B Group areas 41B are provided, and the version (revision) management files 41A1, 41A2, 41A3 and 41B1, corresponding to the source module under development by the group, are provided in the respective areas 41A and 41B. 41B2 and 41B3 are stored.

The work file 5 includes an A group work area (No. 1) 51A1 and an A group work area (No. 2).
51A2, ..., B group work area (1) 5
1B1, ... Is provided and used for editing work such as revision. This group work area is 1 per group
There are one or more. The management mechanism 3 is the version name assigning section 3
1, a source acquisition unit 32, a parallel editing state monitoring unit 33, a branch generation unit 34, and a search mechanism 35. The version name giving unit 31 gives a version name (tag) to the source module. The source acquisition unit 32 extracts the source module in the version management file original 4. The parallel editing status monitor 33 monitors a parallel test version that is not terminated. The branch generation unit 34 adds a version name (tag) to the entire branch to generate a branch. The search mechanism 35 uses the work file 12
The source modules in are compared, and the change difference and the position of the function block are extracted. The communication mechanism 7 communicates with the client machines 8 ₁ and 8 ₂ via the network 16.

Client machine 8₁ , 8₂ Are each
Communication mechanism 9₁ , 9₂ And file sharing mechanism 10₁ , 10₂ 
And storage device 11₁ , 11₂ And registration mechanism 13₁ , 13₂ When
Reference mechanism 14₁ , 14₂ And branch selection mechanism 15₁ , 1
5₂ And a storage device 11 ₁ , 11₂ Each work
File 12₁ , 12₂ Is equipped with. Work file
Le 12₁ A group work area (No. 1) 121A
1, A group work area (No. 2) 121A2, ...
Is provided, and the work file 12₂ In the B group
Business areas (No. 1) 121B1, ...
It

The client machines 8 ₁ and 8 ₂ communicate with the server machine 1 via the network 16 by the communication mechanisms 9 ₁ and 9 ₂ , respectively, and the file sharing mechanisms 10 ₁ and 1 2.
0 ₂ and the file sharing mechanism 6 of the server machine 1, the work file 5 of the server machine 1 shares information with the work files 12 ₁ and 12 ₂ of the client machines 8 ₁ and 8 ₂ . That is, the file sharing mechanism 6
And 10 ₁ and 10 ₂ are storage devices 2 of the server machine 1.
The actual work file 5 in the storage device is as if the work file 12 in the storage device of the client machine 8 ₁ or 8 _2
It has the function of sharing information in real time, making it appear as if there are ₁ , 12 ₂ .

The registration mechanism 13 ₁ , 13 ₂ of the client machine 8 ₁ , 8 _{2 has} a registration procedure for realizing source module management. In addition, the reference mechanism 14
Retrieves information from the original version management file 4 of the server machine 1. The branch selection mechanisms 15 ₁ and 15 ₂ cause the source acquisition 32 of the server machine 1 to register the source module for which the user requests termination of the branch via the interface provided.

Next, an a source module of the first embodiment of the A group of version management method of the present invention, the user to perform editing or the like, from above A group workspace (Part 1) 121 on the client machine 8 ₁ A case of registering in the server machine 1 will be described.

The user uses the reference mechanism 14 to bring a specific version of the source module a ₁ to the A group work area (No. 1) 51A1. Next, the user edits the source module a ₁ using a known editing function (for example, editor).

The user issues a registration request to the registration mechanism 13 in order to register the source module in the A group work area (No. 1) 121A. At this time,
Specify the file name to be registered and the type of registration (distribution / individual editing). The client machine 8 confirms the version number management file original 4 of the storage device 2 of the server machine 1,
The source module of the A group work area (No. 1) 121A is registered in the A group area 41A of the server machine 1 via the communication mechanisms 7 and 9. The revision attached to the registered source module differs depending on the type of registration.

FIG. 2 shows an example of adding a version (revision) to the type of registration.
1.2.1 and the like are registered version (revision) names. Here, the version (revision) managed in parallel in a tree
Are roughly classified into two types. One is a branch for individual editing, and the other is a branch group for distribution.

In this revision control method, as shown in FIG. 2, the user first performs work such as editing of the source module (step 51), and registers the edited source module in a branch for individual editing. (Step 52). Then, it is judged whether or not the source module is in a state in which it can be distributed to other users (group B in this case) who are performing collaborative work (step 53), and until the distribution becomes possible, editing and individual editing are performed. Repeated registration to the branch of "," and stacking the plates (1.1.2.
1, 1.1.2.3, 1.1.2.4 correspond to this). Then, when it can be distributed, the source module of that version is registered in the branch group for distribution while being registered in the branch for individual editing in step 52 (step 54). Which branch of the distribution branch group is registered depends on the distribution form. In other words, all the source modules of the distribution branch do not exist except the files edited by the user in the individual editing branch. These procedures are executed by the program installed in the registration mechanism 13. Also, 1.1.2.1, 1.1.2.3, ...
, Etc. indicate the version names (tags) laterally given to a plurality of source modules forming the a group at a certain time. That is, it can be said that this tag is the version number assigned to the entire source module that constitutes the a group. The tag is requested by the administrator of the server machine 1, that is, the administrator of the database constructed by the revision management method, to the version name assigning section 31 of the management mechanism 3, and the method known by the version name assigning section 31. Attached to the source module by.

In this revision control method, when a source module is edited, when it is in a state in which it can be distributed, the source module edited by each user group is registered because it is registered in the distribution branch group while being registered in the individual editing branch. Module histories are stored separately and only source modules whose identity is known are distributed.

In the revision management method of this embodiment, since the history of the source modules is individually stored and only the source modules whose identity is clear are distributed, there is no confusion in the development due to the combination of the source modules.

Next, the second revision management method of the present invention will be described.
Examples will be described.

FIG. 4 is a flow chart of the procedure of the second embodiment of the revision management method of FIG. 1, and FIG. 5 is a conceptual diagram showing the parallel test version and the common version branch in the revision management method of FIG.

The revision management method of this embodiment is applied when converging branched distribution branches.

In FIG. 5, V5, V6, and V7 are, for a plurality of source modules forming a certain group,
It shows the version name (tag) that is horizontally attached at a certain time. In other words, this tag can say the version number given to all the source modules that make up a certain group. As described above, the tag is requested by the administrator of the server machine 1, that is, the administrator of the database constructed by this revision management method, to the version assigning unit 31 of the management mechanism 3, and the version assigning unit 31 31 is added to the source module by a known method. In FIG. 5, two branches are generated from V5 in the common version branch. That is, for source modules with tags,
The user selects the branch selection mechanism 1 of the client machine 8.
5, when a branch is newly created for the reason that a function is to be added in parallel or the like, a branch of the server machine 1 is transmitted from the interface provided in the branch selection mechanism 15 via the communication mechanisms 7 and 9. Generator 34
Request branch generation. The branch generation unit 34 adds a tag designated by an interface provided in the branch selection mechanism 15 to the entire branch to create a branch by a known method. The branch generated in this way is called a parallel test version.

As described above, when a plurality of parallel test versions are generated for the common version source module, the editing contents such as functions and bug corrections incorporated in the parallel test version are reflected in the common version. There must be. Therefore, next, a branch management method for reflecting the edited contents of the parallel test version branch on the common version branch will be described.

Continuing to refer to FIG. Common version V5
For the parallel test version that is branched from, there are two methods to consider that the branch is terminated, that is, the content is reflected to the common version. These methods are included in the registration mechanism 13 of FIG.

Method 1 Through the interface provided in the branch selection mechanism 15, the user requests the termination of the branch. The branch selection mechanism 15 terminates the source module 32, which is the most recent version or the common version of the version (revision) specified by the interface provided in the branch selection mechanism 15, for the source acquisition 32. Register for the parallel test version of the branch.

In this method, the work of incorporating the edited contents of the parallel test version into the common version is user-dependent. However, generally, in a large-scale software development process, a test is always performed before registering a source module in a database or the like. Therefore, by providing the registration mechanism 13 with the above method, it is possible to avoid the risk that the number of parallel test versions increases.

Method 2 A user requests termination of a branch via an interface provided in the branch selection mechanism 15. For the source acquisition 32, the branch selection mechanism 15 extracts the latest common version source module and the newest tagged common version source module from the group area of the version management file original 4.

Next, the search mechanism 36 causes the source module in the working file 12 to be the newest tagged common version source module, and the newest common version source module to be the newest tagged common version source module. Respectively, and the change difference and the position of the function block are extracted. After that, the change difference between the former and the latter and the position of the function are compared, and whether or not the change contents of the common version and the change contents of the parallel test version are independent for each function is compared by a well-known method. If the edited contents of the former and the latter are independent for each function, the edited contents of the source module in the working file 12 are merged into the newest common version source module by a known method.

In this method, the compilation itself of the edited contents of the parallel test version into the common version is automatically performed. However, if the edited contents of the two branches described above are simply merged by a known method, the operation of the source module after the merge is not guaranteed. Therefore, the search unit 35 limits the unit of merging to a function pair to avoid side effects due to merging.

These two methods are selected by the user when making a registration request to the registration mechanism 13.

The flowchart of FIG. 4 shows the steps from the parallel test version editing and revision to the branch end.

The user edits and registers the source module for the parallel test version described above (step 61). After that, when the user wants to terminate the source module parallel test version, the method 1 or the method 2 is selected (step 62).

When the user selects method 1, the specific file on the common version is registered in the parallel test version (step 63). After that, the parallel edit state monitoring unit 33 is notified that the parallel test version is terminated (step 64).

If the user selects Method 2, the latest common version source module and the latest tagged source module are retrieved (step 65) and each source module is compared with the latest version of the parallel test version (step 65). 66), it is analyzed whether or not the edited contents are duplicated in function units (step 67). If there are duplicates,
The end of the parallel test version is rejected (step 68) and the termination processing is stopped. If they do not overlap, the latest common version source module and the latest parallel test version source module are merged (step 69). Next, register the merged file as the latest version of the common version (step 70), and finally,
The parallel edit state monitoring unit 33 is notified that the parallel test version is terminated (step 71).

For the parallel test version that has not been terminated in step 70, the database administrator monitors the parallel edit status monitor 33 at any time, and issues a warning to the creator of the branch that remains for a long time. Can be emitted.

In this revision control method, when the user simultaneously edits two or more edits on the same source module, the edits can be smoothly performed, and the contents of the parallel edits can be appropriately reflected in the common version. Yes, and
You can monitor the status of parallel editing.

According to the revision management method of this embodiment, when the source modules are distributed among a plurality of developers and co-developed,
It avoids confusion due to parallel editing and enables smooth implementation.

[0050]

As described above, according to the present invention, when the source program registered in the individual editing branch becomes ready for distribution, the source program is registered in the distribution branch group as it is, which is required by the developer. There is an effect that it is possible to avoid confusion in the development of the source module because the source module to be referenced can be surely referred to by only one procedure and only the source module whose identity is clear is distributed.

Further, when the parallel edition branch is extended from the common edition branch of the source module by, for example, registering the specific edition in the common edition branch in the parallel edition branch and terminating the parallel edition branch. There is an effect that the contents are properly reflected in the source modules that are distributed throughout, the orderly parallel editing is performed, and the source module distribution is not confused.

[Brief description of drawings]

FIG. 1 is a configuration block diagram of a program development network to which an embodiment of a revision management method of the present invention is applied.

FIG. 2 is a flowchart of a procedure of a first embodiment of the revision management method of FIG.

FIG. 3 is a conceptual diagram showing individual editing and distribution branches in the revision management method of FIG.

4 is a flowchart of a procedure of a second embodiment of the revision management method of FIG.

5 is a conceptual diagram showing a parallel test version and a common version branch in the revision management method of FIG.

FIG. 6 is a conceptual diagram of a conventional example of a revision management method.

[Explanation of symbols]

1 server machine 2, 11 ₁ , 11 ₂ storage device 3 management mechanism 4 version number management file original 41A A group area 41A1, 41A2, 41A3 version management file 41B B group area 41B1, 41B2, 41B3 version management file 5, 12 Work files 51A1, 121A1 A group work area (No. 1) 51A2, 121A2 A group work area (No. 2) 51B1, 121B1 B group work area (No. 1) 6, 10 ₁ , 10 ₂ File sharing mechanism 7, 9 ₁ , 9 ₂ Communication mechanism 8 ₁ , 8 ₂ Client machine 13 ₁ , 13 ₂ Registration mechanism 14 ₁ , 14 ₂ Reference mechanism 15 ₁ , 15 ₂ Branch selection mechanism 16 Network 1.1, 1.2, ~ 1.4, 1 1.2.1.1, 1.1.
2.2, 1.1.2.5 Revision V5, V6, V7 Version name

Claims (2)

[Claims] 1. A server machine having a version management original storage area for storing a plurality of source modules that constitute a program in module units, and a revision of the source module in the version management original storage area of the server machine. A revision management method for the source module in a program development network having a plurality of client machines used jointly by a plurality of user groups, wherein the registration mechanism manages the version number of the server machine. When registering a revision of a source module in the original storage area, after individually editing the source module and registering it in the individual editing branch, the source module becomes available for distribution to other user groups. Individual editing bra While registered to Ji, revision control method characterized by comprising the step of registering the distribution for the branch group. 2. When the revision of the source module is registered in the version management original storage area of the server machine,
When the parallel edit branch is extended from the common version branch of the source module, the specific version in the common version branch is registered in the parallel edit branch, and the parallel edit branch is terminated with that.
Or, the difference from the version tagged with the latest public version to the latest common version, and the difference from the version tagged with the latest public version to the latest parallel edition version In the function unit, and when the edited contents do not overlap, merge the latest common version and the latest parallel edited version, and check the stage of terminating the parallel edited branch and the existence of unfinished parallel edited branch The revision management method according to claim 1, further comprising: