JPH09223054A - File set management device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the burden or worker by handling the files in every set of plural files and also performing the version management in every file set. SOLUTION: The hosts 101, 102... are connected to each other via a communication circuit 14 in a computer network. The file set management device of these hosts consists of a repository 6 serving as a file storage means and a work space 8. In the space 8, every worker performs the production, updating, etc., of programs. Then, the repository 6 stores the file of programs produced in the space 8. The files are read out of the repository 6 and also stored there in every set of files. At the same time, the version management is carried out for every set of files.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a file set management device for managing a component such as a computer program, which is composed of a set of a plurality of files.

[0002]

2. Description of the Related Art When a large-scale computer program is developed, the program is divided into a large number of constituent elements having a specific function, and a plurality of workers create a program for the constituent elements that they are in charge of. In many cases, a method of synthesizing these to complete one large program is adopted. The divided program of each component is generally composed of a set of a plurality of files. A set of files in which a text file or the like describing the functions of the constituent elements is attached to the constituent elements of such a program is called a component. Since this part is associated with a particular function, the operator thinks of the program on a part-by-part basis rather than on a file-by-file basis. For this reason, it is convenient for an operator to handle a file if it can handle a set of files constituting this component as a unit.

As a method of handling a component composed of such a plurality of files as a unit, there is a method of attaching a tag for identifying the component to which each file belongs. By this, the worker can know which part the file belongs to by looking at the tag. Also, for example, when all the files belonging to a certain part are needed, it is possible to easily retrieve only the files belonging to that part from the repository to the workspace by issuing a read instruction using the tag as a parameter. .

[0004]

By the way, when the number of files constituting the entire program is in the range of several thousand to tens of thousands, the number of parts is also large, and the parts cannot be found by just looking at the tag name. It is difficult to understand immediately what it is. Also, when multiple workers share parts in the repository, when one worker extracts the necessary parts from the repository into the workspace, improves it, and registers it again in the repository, the past version and the latest version are used. Other workers should be aware of the relationship with the version. Further, there is a case where there is a hierarchical relationship between the parts, as in the case where not only the file but also another part is combined to form one new part.

Conventionally, there is no tool for automatically and efficiently managing a large number of files and parts, and an operator prepares a dedicated ledger, and the relationship between the tag name and the function or content of the part, or the part hierarchy. By using the method of describing relationships etc. in this ledger, each file and part was managed by human hands. The present invention has been made based on the above circumstances,
An object of the present invention is to provide a file set management device that enables an operator to efficiently handle necessary files and parts.

[0006]

According to a first aspect of the present invention for solving the above problems, a file is read from a storage unit and a file is stored in the storage unit in units of a file set including a plurality of files. In addition to storing, version management is performed in units of the file set.

According to a second aspect of the present invention, in the first aspect of the invention, the file set includes a file that constitutes a part of a computer program. The invention according to claim 3 is the invention according to claim 1, wherein the file set includes a document file.

The invention according to claim 4 is the invention according to claim 1, 2, or 3, characterized in that the file set includes another file set.

[0009]

For example, when a large number of workers share one program and develop one program, each worker is provided with a component that is a part of the program and can realize some cohesive function or procedure. Often assigned as development. In order for a program to realize one set of functions or procedures, various files are usually required, and when these are translated into object code by a compiler, each file is placed in the directory required by the compiler. It is necessary to put it. In such a case, if the file management is performed for each individual file, the file management becomes complicated because the directory of each file is different. Further, when the version upgrade is repeated and there is a file having a plurality of version numbers, it is difficult for each worker to remember which version of the file to use.

Therefore, a plurality of files to be handled by the worker when he / she actually works are defined as a specific file set, named, and handled as a unit. This file set can also include another file set. Once this file set is defined, version management can also be performed in units of this file set. When reading a file from the repository, which is the storage means of the file, all the necessary files can be retrieved with one operation using the name of the file set as a parameter. At that time, even if the file in that file is upgraded several times and the worker forgets which version was used in that file set, if the file set is handled as a unit, The necessary files can be retrieved without problems, and the burden on the operator is reduced.

[0011]

DETAILED DESCRIPTION OF THE INVENTION An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing the configuration of the file set management apparatus of this embodiment. However, this is a conceptual configuration that the worker is aware of, and is different from the actual hardware configuration. As shown in FIG. 1, the file set management device of this embodiment includes a repository 6 and a workspace 8. The workspace 8 is an area where each worker performs work such as program creation and update, and the repository 6 is an area where program files created in the workspace are stored. Although only one workspace 8 is shown in FIG. 1 for the sake of clarity, in reality, there are as many workspaces 8 as there are workers working in parallel.

FIG. 2 is a block diagram showing an example of a computer network system for applying the file set management apparatus of this embodiment. As shown in the figure, each of the hosts 10 ₁ , 10 ₂ , ...
Connected to each other. These hosts are, for example, computers such as workstations and have a memory, a CPU, a hard disk, etc. inside.
The repository 6 and the work space 8 shown in FIG. 1 exist only as a logical concept, and a host for these exists is not particularly determined. The file currently being created or modified in the workspace 8 and the file stored in the repository 6 are physically on the hard disk of an appropriate host designated by the file set management apparatus. When the worker instructs to retrieve a specific file from the repository 6, the hard disk of the host storing the file is accessed to read the file, and the communication line 1
4 to the worker's workspace. Therefore, the worker does not need to be aware of where the file is stored. It should be noted that in the present embodiment, the reading or storing is not performed for each single file, but the reading or storing is performed in units of the component structure composed of a plurality of files. This "component structure" will be described later.

Generally, when a large-scale program is developed with the cooperation of a large number of workers,
Development of a program, which is a component of the program and can actually execute a specific function, is allocated. In order to develop a program capable of realizing a function assigned to development, each worker further divides the function into a plurality of appropriate parts, and performs programming etc. with each of the divided parts as one file. . In this way, the plurality of program files created by one person in charge of development are constituent elements that realize part of the functions of the entire program.

The program which is each component of the whole program created in this way is translated into an object code by a compiler, and then the object code of the program developed by each worker is linked, It is put together in one machine language computer program. When translating the source code of each component created by each worker into an object code using a general compiler, the source code file existing in the workspace is
It must be stored in the predetermined format determined by the compiler. However, this "predetermined format"
Is a directory hierarchy that is convenient for the compiler to translate the source code into object code, and is not a convenient format for a worker to develop a program. The files that make up that part of the program generally belong to different directories. Therefore, it is difficult to manage the program for each file, which is the minimum unit.

Therefore, it is more convenient for the worker to handle a plurality of files having a certain relationship as a unit, rather than handling them in file units. The "plurality of files" is, for example, a text that describes a plurality of program files that make up some of the components of the entire program that are in charge of development, and a description of the functions of this part of the program. For example, a file.
At that time, if the combination of the file name and path name of each file is regarded as a file name, it is not necessary to consider which directory each file belongs to.

From the above point of view, in the present embodiment, a plurality of files which are constituent elements of the program and realize a specific function or procedure (or a single file when the constituent elements are small in scale) Good) and, if necessary, a document file that describes the functional description of such components, etc. is defined as a "part structure",
Version management and other processing are performed using this component structure as a unit. Further, one component structure can include not only a file but also another component structure, which is called a sub-component structure. However, a part structure that does not include any part structure or a part structure that includes only a part structure and does not include any file can exist.

FIG. 3 is a diagram showing an example of the structure of the component structure. One part structure includes "name of part structure", "version number of part structure", "information stored in repository", "file name of file managed by part structure", "part structure" In the workspace of the sub-parts structure managed by. In the "storage information in repository", for example, when the component structure is modified and then stored in the repository, information on the storage position is described. The "file name of the file managed by the component structure" is accompanied by the path name of the file. The actual entity of the part structure is the multiple files and sub-part structure that actually compose it, but the part structure definition file is an independent file that describes the information necessary to define the part structure. It is one file. The component structure defined in this way is registered in the repository 6. The repository 6 stores a plurality of files or sub-component structures included in the component structure as a unit. Therefore, for example, when the same file is included in a plurality of component structures, each component structure is stored in the repository including the file.

The files and sub-component structures that make up one component structure may be of any type and are not particularly limited, but generally, a program that realizes a specific function handled by one operator is used. Collect necessary files and sub-part structures as one part structure. Further, file version management is also performed in units of this component structure. That is, when the file included in the part structure is updated, the version number of the part structure is automatically updated according to a predetermined format.

FIG. 4 shows the relationship between the parts structure stored in the repository 6 and the structure of the parts structure in the workspace 8 and the directory of the file actually applied to the compiler in the file management apparatus of this embodiment. It is the figure which showed typically. In the figure, the repository 6 stores seven component structures A, B, C, D, E, F, and G. A number such as “1.1” connected from each component structure indicates the version number of the component structure. Each part structure includes a plurality of files (not shown) that make up the part structure.
In some cases, the part structure includes another sub-part structure. The inclusion relation between the component structures is indicated by the symbol “sub”. Specifically, version 1.1 of part structure D includes all versions of part structure E, and version 1.1 of part structure G includes all versions of part structure E. I'm out. Some part structures have a plurality of version numbers due to version upgrade. Files are stored in the repository 6 in units of part structures. Therefore, regarding the files included in the part structure to be upgraded, each file exists in the repository for each part structure of each version number. Become. Each component structure is stored in the repository 6 using, for example, a commercially available data management system,
It is stored for each component structure in a data compressed form.

When an operator reads out a required component structure into his / her workspace 20, he inputs the storage location information and instructs the read out, the configuration management tool 21 shown in FIG. Access and read the part structure. As a result, the files and sub-component structures included in the component structure are collectively read from the repository 6. Therefore, also in this case, the worker can proceed with the work in the component structure unit without paying special attention to the necessary file and its version number. Then, work such as maintenance and debugging is performed on the read component structure, and when the work is completed, it is stored again in the repository 6 or translated by the compiler 23. In this way, the present inventor newly developed a program called the configuration management tool 21 in order to be able to operate in units of component structures. The configuration management tool and the part structure definition file are integrated, and the file can be handled in units of the part structure.

22 ₁ on the right side of the workspace 8 in FIG.
The large number of squares indicated by 22 ₂ , ...
3 shows a file to be translated by 3. These files schematically show that they have the directory structure required by the compiler 23. Each file 22 ₁ , 22 ₂ , ... Is always included in one of the component structures, but at the same time, it is designated to belong to a specific directory so as to meet the condition imposed by the compiler 23. ing. This specification
The path name to the directory to which the file belongs is described in the file name of each file. When a file is created, the type and function of the file make it possible to know in advance which directory the file should belong to when viewed from the compiler. Therefore, the worker attaches a predetermined path name to the file name when creating the file. By specifying the path name in this way, even if the files are handled in units of component structures, the files can be arranged according to the hierarchical structure of the directories that can be finally processed by the compiler. However, at the stage when the worker stores and reads each file in the repository, it is not necessary to be aware of the directory related to the file, and the hierarchical structure of the directory required by the file processing tool such as the compiler is not necessary. Without worrying about it, you can handle all the files necessary for the work you are in charge as a whole.

After the development of the required program for each component structure is completed, the files included in the component structure can be translated by the compiler in the workspace 8. The object code program 24 thus obtained is combined with a translated version of another component structure by using a tool such as a linker, if necessary, and finally one machine is created. It is a language program.

The present invention is not limited to the above-mentioned embodiments, and various modifications can be made within the scope of the gist thereof. For example, in the above-described embodiment, the present invention is applied to a network of workstations each called a host, but the present invention can also be applied to a computer network system including, for example, a server and a client. .

In the above embodiment, the case where the file set of the present invention is a parts structure including a part of program files and document files has been described. However, this file set is a set of only program files. It may be a set of only document files (for example, manuals are described).

[0025]

As described above, according to the present invention,
By handling files in units of a file set consisting of multiple files, the worker only needs to upgrade, store in the repository, and read from the repository in units of multiple files. In addition, even if there is a hierarchical relationship between file sets, it is not necessary for humans to manually manage the relationship between each file set, and file set management that greatly reduces the burden on workers A device can be provided.

[Brief description of drawings]

FIG. 1 is a diagram showing a relationship between a repository and a workspace.

FIG. 2 is a block diagram showing an example of a computer network system to which the file set management device of this exemplary embodiment is applied.

FIG. 3 is a diagram showing a configuration of an example of a parts structure definition file.

FIG. 4 is a diagram schematically showing a relationship between a component structure stored in a repository and a configuration of the component structure in a workspace and a directory of files actually applied to a compiler.

[Explanation of symbols]

6 repository 8 workspace 10 ₁ , 10 ₂ ... terminal 12 host computer system 14 communication line 21 configuration management tool 22 ₁ , 22 ₂ , ... file 23 compiler 24 program

Claims (4)

[Claims] 1. A file set consisting of a plurality of files is used as a unit to read a file from a storage unit and store a file in the storage unit, and to perform version management in a unit of the file set. File set management device. 2. The file set management device according to claim 1, wherein the file set includes files that form part of a computer program. 3. The file set management device according to claim 1, wherein the file set includes a document file. 4. The file set management device according to claim 1, wherein the file set includes another file set.