JP3078091B2 - Source module version control method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to development management of large-scale programs developed by a plurality of developers, and more particularly to a version management method of source modules constituting a program.

[0002]

2. Description of the Related Art A program whose version has been updated in the course of development by leaving a history of program development,
In order to manage the supply of each version, there is a version control system for program and source code. FIG. 4 is an explanatory diagram showing a conventional file configuration example of such a version management system.

Referring to FIG. Version (version)
From 1.1 to 1.2, 1.3, 1.4, 1.4
, There is a case where there is a branch that proceeds to 1.4.1.1, 1.4.1.2, and a case that proceeds to 1.5.

[0004] Here, it is shown that the version 1.4 is made by a person A and the version 1.4.1.2 is made by a person B. As shown in FIG. 4, the version management file for managing the transition of the version (version) includes log information, source information, difference information between each version,
Contains.

That is, the conventional version management system has a mechanism in which an arbitrary registered source module can be obtained by recording the registration history in one source module as difference information. In addition, at the time of registration, it is possible to manage the editions in parallel in a tree shape by specifying which of the already registered editions is to be recorded with the difference information. By describing the symbol information for the registered version in the version management file, the supply of the registered version is managed.

[0006] References describing such prior art include the following. [1] Walter F. Tichy “Design, Implementation, and Ev
aluation of Revision Control System "6th ICSE, IEEE
Sep.1982 [2] Brian Berliner “CVS II: Parallelizing Softw
are Development "Can be found on uunet.uu.net in f
tp / packages / gnu / dvs-1.2tar.Z

[0007]

[Problems that the Invention is to Solve The conventional source code management system is composed of a plurality of source modules,
When applied to source module management of large-scale software involved in development by a large number of people, there are the following disadvantages.

(1) When registering a source module, it is necessary to send a file from the machine that is developing the source module to the server machine, and when acquiring the source module, it is necessary to send a file from the server machine to the development machine. There is a security problem because users have equal access.

(2) Supply management can be performed for individual source modules at the time of registration or by adding symbol information. However, sets can be associated with each work type across source modules, and files with corresponding versions can be assigned. You couldn't get them all at once.

[0010] (3) The registration status of each source module can be easily grasped by referring to the log of the management file, but it is not possible to easily check the entire source module.

[0011] It is an object of the present invention to solve the above-mentioned drawbacks. In order to solve the above-mentioned drawbacks, a registrant who can register and acquire from a client machine corresponding to a user via a network is limited to a source module . Can be limited only to registrants from client machines,

It is an object of the present invention to provide a source module / version management method capable of performing version control across source modules and referring to the registration status of source modules collectively.

[0013]

In order to achieve the above object, according to the present invention, a source module / version control system comprises a server machine, one or more client machines, and a communication mechanism for connecting the two. Keep it. And

(1) Using a communication means (communication mechanism) between machines via a network, the client machine directly accesses the corresponding file of the server machine at the time of registration, and the server machine searches for the corresponding file at the time of acquisition. Send to client machine

(2) There is a mechanism for managing the entire version management file of the source module, and this gives common symbol information to the corresponding version of each version management file.

(3) The management mechanism of (2) has a function of searching each version management file and extracting all versions having the corresponding symbol information.

(4) The management mechanism of (2) has a function of searching the symbol information and registration history of each version management file and creating a list of the latest registration information and the latest supply information. And

[0018]

According to the feature of (1), the registrant can register from the client machine without sending the corresponding source module to the server machine. Acquisition is performed by sending an acquisition command to the server machine, and the server machine is directly connected to the client machine. Since the desired file is transferred, the file can be obtained on the client machine without placing the file on the server machine.

According to the feature (2), the correspondence between the version of the source module itself and the release version can be taken, so that version control can be performed across source modules.

According to the feature (3), the source modules constituting a certain release version can be obtained collectively without being aware of which version each is.

According to the feature (4), the source modules constituting a certain release version are collectively determined without checking each version, or what information is written in the log of the version. To see the registration status.

[0022]

Next, an embodiment of the present invention will be described with reference to the drawings. Embodiment 1 FIG. 1 is a block diagram showing an embodiment of the present invention. In the figure, 1 is a server machine, 2 is a management mechanism, 21 is a log creation unit, 22 is a version name assignment unit, 23 is a source acquisition unit, and 24 is a search function unit.

In addition, 3 is a storage device, 31 is a version management file, 31A is an A user area, 31B is a B user area, and 4 is a communication mechanism. 5 is a client machine,
6 is a communication mechanism, 7 is a registration / function unit, 9 is a network,
It is.

Referring now to FIG. A user is a unit of a group in charge of creating a source module, and a plurality of client machines 5 are used for development for each user . The server machine 1 is a machine that manages a source module. User client machine 5
The server machine 1 and the server machine 1 have communication mechanisms 6 and 4 which are mounted as standard, and communicate with each other via a network 9.

The storage device 3 of the server machine 1 has a user
The user areas 31A and 31B are provided corresponding to the user , and a version management file is stored in the user areas 31A and 31B corresponding to the source module for which the user is responsible for development. First, an example in which a source module under development on the client machine 5 of the A user is registered in the server machine 1 will be described.

The user issues a source module registration request to the registration / reference function unit 7 of the user client machine 5. At this time, the file name to be registered and the type of registration (release between groups / release within group / individual distribution) are specified. The client machine 5 has confirmed A user area 31A of the server machine storage device 3, via the communication mechanisms 6,4, the server machine 1 A user
The file on the client machine 5 is registered in the version management file corresponding to the specified source module in the area for area 31A. The registration method differs depending on the registration type.

FIG. 2 is an explanatory diagram showing an example of version management of each source module. In FIG.
5.1.1 and the like are registered version names. V5 and the like are release names between groups. V5R1 and the like are in-group release version names. V5P1 and the like are individual distribution version names.

According to this example, when the next registration file is designated as "inter-group release", the registration version is set to 1.6 and registered as a 1.5 difference file. When "release within group" is designated, the release version number between groups is also designated at the same time, and when the version number is V6 or omitted, the registered version is set to 1.5.2.3 of the branch of V6 to 1.5. .
It is registered with the difference file of 2.2.

In the case of "individual distribution", the release version number between groups is also specified at the same time, and when the version number is V6 or omitted, the registered version is set to 1.5.1.4 of the branch of V6 to 1.5. .1.3 is registered. At this time, at the same time as registration, a symbol corresponding to an individual distribution version name of V5P3 is given by a known method.

Embodiment 2 An example of cross-version name assignment between files will be described. Source modules are divided into files. One file belongs to a plurality of file groups, and the file group to which the file belongs is identified by the version management name and the directory name in which this file is stored.

When synchronizing a specific file group, the file manager instructs the management mechanism 2 of the server machine 1 to give a version name. At this time, the registration type, version name, and file group are specified. If the registration type is specified as "release between groups", the management mechanism 2 searches all user areas by directory name and file name, and finds the version of the source module belonging to the specified file group. When the management file is found, the latest registered version is specified from among the files (files with a registered version with two digits, such as 1.1, 1.2) specified by specifying the release between groups in the management file. A release name between groups is given by a known method.

FIG. 3 is an explanatory diagram showing an example in which V2 of an inter-group release is given to the file group B. The registered version number 1.5 for module A and the registered version number 1.6 for module B are the latest registrations, respectively, and a symbol V2 is assigned to each.

[0033] On the other hand, if the "group in the release" is specified, the management mechanism 2, to search for all of Yu over The area in the directory name and file name, version of the source modules that belong to the specified file group The management file is found and a predetermined symbol is assigned. An example of symbol assignment will now be described with reference to FIG.

When the designated version name is V6R2, of the branches to which the symbol of V6 is assigned, 1.5.2. Of the x series, the symbol V6R2 is assigned to the latest registered version 1.5.2.2 by a known method.

Embodiment 3 A method for acquiring a file will be described. The user who acquires the source file sends the registration / reference function unit 7 from the client machine 5 to
Issues a source module acquisition request. This request includes acquisition for each source module and acquisition for each file group of the source module. In the case of acquisition for each source module, specify the source module name, registration type, and version name.

When the version name is omitted, it means that the file with the latest version number is obtained. The registration / reference function unit 7 of the client machine 5 instructs the management mechanism 2 of the server machine 1 to acquire a file via the communication mechanisms 6 and 4. When the management mechanism 2 searches the management file for all users and finds the specified file, the management mechanism 2 acquires a registered version file having the specified version name of the specified registration type by a known method. Is sent to the requested client machine 5 via the communication mechanisms 4 and 6.

The reference function unit 7 of the client machine 5
Upon receiving a reply from the server machine 1, the source module is stored in its own storage device. In the same way, when acquiring for each file group, the management mechanism 2 of the server machine 1
, The management mechanism 2 searches the management file for all users , finds a file belonging to the specified file group from the file name and directory name of the source module version management file, and A file of the registered version to which the specified version name is assigned is acquired by a well-known method, and is sent to the requested client machine 5 via the communication mechanism.

This is performed for all the source modules belonging to the specified file group. Client machine 5
Receives the reply from the server machine 1 and stores the source module in its own storage device.

Embodiment 4 The reference function unit 7 of the client machine 5 issues a reference request for the attribute of the specific source module to the server machine 1. The management mechanism 2 on the server machine 1 stores the history left by the existing version management method,
The correspondence history left by the management method of the first or second embodiment is scanned, a registration / release history slip for the source module is created, and sent to the client machine 5. The reference function unit 7 of the client machine 5
Receives a reply from and presents the result to the referrer.

Embodiment 5 The reference function unit 7 of the client machine 5 issues a reference request to the server machine 1 regarding the registration status of a specific registration type (release between groups / release within group / individual distribution). At this time, a group of files is also specified. If the file group is omitted, it means all the managed source modules.

When the management mechanism 2 of the server machine 1 searches the management files for all users and finds the version management file of the designated file group, the log information (log information) held by a well-known method is obtained. Registrant, registration date and time), the latest registered version of the specified registration type, and the first embodiment corresponding to this version.
Alternatively, the symbol information (version name) given by the method 2 is checked, a list of source modules constituting the file group is created, and sent to the client machine 5.

The reference function unit 7 of the client machine 5 receives the reply from the server machine 1 and presents the result to the referrer.

[0043]

According to the present invention, a user can register and acquire a file directly from a client machine without logging in or transmitting a file to a server machine. There is an advantage that the registration status can be referred to and acquired without passing through a plurality of files without referring to and acquiring files.

In addition, by doing so, the
When the method is applied to the development of large-scale software, not only does the user's effort be reduced, the time required for file distribution is shortened, but also the load module file caused by the file acquisition error caused by the large number of file acquisition efforts Prevent creation rework. In addition, since only registered users can be updated, security is guaranteed. In addition, the correspondence between the registration status and the registration history and the release can be easily grasped. This facilitates management of the entire development project.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a system configuration according to an embodiment of the present invention.

FIG. 2 is a conceptual diagram of a version management method for a specific release according to the present invention.

FIG. 3 is a conceptual diagram of a version management method relating to a plurality of releases according to the present invention. FIG.

FIG. 4 is a conceptual diagram of a conventional source module version management method.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 1 ... Server machine, 2 ... Management mechanism, 21 ... Log creation part,
22: Version name assigning unit, 23: Source obtaining unit, 24: Search function unit, 3: Storage device, 31: Version management file, 31A
.. A user area, 31B B user area, 4 communication mechanism, 5 client machine, 6 communication mechanism, 7 registration / functional section, 9 network

Continuation of the front page (56) References JP-A-1-263746 (JP, A) "The 32nd (Early 1986) National Convention Lecture Papers (I)", Information Processing Society of Japan, Showa March 61, p. 719-720 "41st (late 1990s) National Convention Lecture Papers (5)", Information Processing Society of Japan, September 1990, p. 5-255-5-256 "42nd (Early 1991) National Convention Lecture Papers (5)", Information Processing Society of Japan, March 1991, p. 5-333-5-334 "42nd (Early 1991) National Convention Lecture Papers (5)", Information Processing Society of Japan, March 1991, p. 5-337-5-338 Hideaki Tsuboi, 4 others, "C Program Development Environment Using Configuration and Version Management Library LifeLine", Information Processing Society of Japan Research Report, Information Processing Society of Japan, July 1990, Vol. 90, No. 62 (90-SE-73), p. 107-114 (58) Field surveyed (Int. Cl. ⁷ , DB name) G06F 9/06, 9/445, 12/00

Claims (4)

(57) [Claims] At least a storage area for holding a plurality of source modules constituting a program in module units, a search and retrieval mechanism for searching and extracting the source modules stored in the storage area, and a communication mechanism are provided. The server module includes one or more client machines including at least a server machine, a registration mechanism, a reference mechanism, and a communication mechanism.
Ri, a storage area in the server machine, each user
It is allocated as a unique area for each client machine corresponding to the user , and at the time of registration, the source module to be registered reaches from the client machine corresponding to the user to the communication mechanism on the server machine side via the registration mechanism and the communication mechanism, From there, only the unique area allocated to the client machine in the storage area is registered . At the time of reference, a signal designating a source module to be referred is transmitted from the client machine to the server via the reference mechanism and the communication mechanism. Arriving at the communication mechanism on the machine side, and searching the entire storage area to fetch the desired source module to be referred to from there by a search fetching mechanism.
Source module and version control
Method. 2. The source module / version management method according to claim 1, wherein any of the source modules held in the storage area on the server machine side includes:
The method includes a step of searching and retrieving all the same release version (version) names managed by the source module by specifying the version (version) name once from the client machine side. Source module management method. 3. The source module / version management method according to claim 1, wherein the server machine has a log creation mechanism, and a registration history of each source module to be held in the storage area is registered. edition and, the
A source module management method , comprising: creating a correspondence table of a combination of a registration history and a registered version by the log creating mechanism, and referring to the table from a client machine . 4. The source module / version management method according to claim 1, wherein :
In the storage area of the server machine, each client module refers to the registered state in the storage area of the server machine from the client machine in the form of a list of all source modules .
Source module management method characterized by including steps
Law.