TWI550423B - File access device, method and computer program for software version control - Google Patents

Description

File inventory device, method and computer program product for software version control

The invention relates to a file inventory taking device, a method and a computer program product thereof, in particular to a file inventory taking device, a method and a computer program product thereof for software version control.

The current file management system uses the storage space effectively. When the version file is stored (for example, the source files of multiple dependent versions), the difference between the versions is compared, and only the next version is stored. Differences from the previous version to save storage space.

When the archive stores the binary file (for example: executable file, image file, image file), even if there is only slight difference in the content between the two files, the system does not compare exactly when the binary file is compared. The difference between the two. Therefore, when storing the binary file, the above functions cannot be achieved.

When the amount of data in a file is large, the amount of data in the archive is likely to exceed the amount of data that can be carried by a single disk. And because of the interdependence requirements of the versions, the archive does not allow arbitrary deletion of some versions of the content to avoid the dependency of the lost files. Therefore, if the stand-alone archive space is full, the new version of the data will no longer be stored.

In summary, how to provide a technology that can release an archive that affects the version-related requirements when the archive space is full is a technical problem that needs to be solved in the field.

In order to solve the problems disclosed above, the object of the present invention is to provide a software version. The control file storage device, method and computer program product.

In order to achieve the above objective, the present invention provides a file inventory taking device for software version control, which comprises: receiving a software version file from the outside, and checking the software version file into one of the external plurality of archives, and When the storage capacity of the archive in the active state exceeds the allowable storage amount, the archived time information according to the access records of the archives is selected to select the archive file for the connection.

To achieve the above objective, the present invention provides a file inventory taking method for software version control, which is applied to a computer device and includes the following steps: receiving a software version file from the outside. And the software version file is checked into one of the external plurality of archives, and in the active storage of the archive, the storage capacity exceeds the allowable storage amount, and the time information of each of the archives is used to select the time information to select The archive of the continuation role.

To achieve the above object, the present invention provides a computer program product for software file control of a software version control. When the computer device loads and executes the computer program product, the steps described in the method can be completed.

In summary, the file inventory taking device, method and computer program product of the present invention can select and release a specific storage space to store the subsequent software version file in the archive storage space.

10‧‧‧Archive stock picking device

11‧‧‧Use side

12‧‧‧Software version file

13‧‧‧Archive

S101~S108‧‧‧Steps

S201~210‧‧‧Steps

FIG. 1 is a schematic diagram of a file inventory taking system for software version control according to an embodiment of the present invention.

2 to 3 are flowcharts of a method for taking a file inventory for software version control according to another embodiment of the present invention.

The specific embodiments are described below to illustrate the embodiments of the invention, but are not intended to limit the scope of the invention.

Please refer to FIG. 1 , which is a schematic diagram of a file inventory taking system for software version control according to an embodiment of the invention. The system includes a file inventory retrieval device 10, a usage terminal 11 and one or more version control archives 13. The file inventory taking device 10 is a communication connection terminal 11 device and a plurality of version control archives 13 (hereinafter referred to as archives 13). When the external user terminal 11 submits the software version file 12 to the file inventory retrieval device 10, the file inventory retrieval device 10 is triggered to commit the software version file 12 to the predetermined archive library 13 when the file is scheduled to be checked in. When the storage capacity of the library 13 exceeds the allowable storage amount, the access record time information of the other archives 13 is analyzed to select the archive 13 of the software version file 12 that is successively checked in. For example, the file inventory taking device 10 can select the new and old order of the access time information as the selection condition (for example, analyzing the last transaction time of each archive 13 and selecting the archive database 13 with the earliest time as the file to be checked in again). Library 13). After the selected archive 13 is selected, the archive 13 is reset. Since the partial archive 13 does not have a delete command, the archive inventory take-up device 10 switches to the operating system layer in this case. The archive 13 is deleted to free up space, and an archive 13 is reset to complete the reset operation. After the reset operation is completed, the file inventory taking device 10 can check the subsequent software version file 12 into the reset archive 13.

The aforementioned use terminal 11 and the file inventory taking device 10 are computer devices or electronic devices capable of computing power. The software version control of this case can use Apache Subversion. The software version file 12 contains binary files (such as executable files, image files, and image files).

Please refer to FIG. 2 and FIG. 3 , which are a file inventory taking method for software version control according to another embodiment of the present invention. The method can be applied to a computer device. In another implementation, the method can be applied to the foregoing. The file inventory taking device 10, the flow chart of which is as follows.

S101: Determine the currently active archive. Since there are many archives available for registration in the computer device, it is necessary to first determine which archive is active when actually checking in the file. In the first execution, an archive can be arbitrarily selected as the active archive. In the subsequent execution of the file check-in, the final write time will be used as the basis for judgment.

S102: Is it determined that the archive space in the active space is sufficient? If yes, execute S107; if no, execute S103.

S103: Determine the recycling space. See Figure 3 for the details of the process. If the internal space is sufficient, S104 is performed; if not, S108 is performed.

S104: Rebuild the archive. The file system of the consideration part does not provide a delete instruction itself. At this time, the archive can be deleted from the operating system layer, and the archive can be regenerated to release the space of the archive and record the time of the transaction.

S105: Specify an active archive. The archive reconstructed via S104 will now be designated as the active archive. If the reserved operation is executed in the foregoing step (S103 detailed process), the archive that was originally set as the reserved space is changed to be active, and the archive is reserved.

S106: The file needs to be kept in storage. If there is a file to be retained at S103, it will be stored in the active archive and the stored archive, relative path, version, and final transaction time will be recorded.

S107: Deposit the submitted file collection in the active archive. In this step, the relative path of the software version file and its version, and the final transaction time are stored in the active archive.

S108: The return space is insufficient.

The foregoing reserved operation takes more time to reconstruct the configuration of the archive, so when the application context requires a higher response time, the reserved operation can be performed. Further, the reserved operation refers to a new space generated by the emptying of each switched archive, which is used as the next handover. In other words, the space used to set the active archive this time is generated at the previous switch. Since the space has been sorted out in the previous switch. Therefore, the execution speed will be improved only when the switching operation is performed. The actions of arranging the archive space are executed synchronously at the time of switching. The execution of the aforementioned reserved jobs will take up more space in one archive. That is, if there are n archives, there will be only n-1 spaces available.

The flow of Fig. 3 is a detailed flow chart for calculating the file space in Fig. 2, S103, which is explained as follows:

S201: Determine whether to execute a reserved space job. If yes, execute S203; if no, execute S202.

S202: Obtain all archive lists, sorted by the old and new time of the last transaction time. All the archives registered in the system are sorted from old to new by the last transaction time recorded in S107, so as to preferentially handle the archive space with the older content.

S203: Determine whether the reserved space is sufficient to store the submitted software version file. If yes, then S210 and S205 are executed. The foregoing steps select the pre-space to be used next on the one hand, and continue the conversion of the archive on the other hand. When the space is not enough, the representative needs To recalculate the appropriate space to be used as the active archive, and then execute S202.

S204: Read the next archive sequentially. The computer device reads the archive set one by one for execution of steps S206 to S208.

S205: Obtain a list of archives, sorted from old to new (excluding the archive that is currently reserved).

S206: Organize and rebuild the archive list of the archive to be retained, and then execute S208. Because the next S104 will clear the selected archive, the comparison benchmark when calculating "whether there is enough space to save the file", in addition to S102's "this file collection size", you need to confirm the current comparison. The archive, if it stores files that are not available in other archives, when it is emptied, it will cause the file to be incomplete. This phenomenon was originally used in a single file. In order to confirm whether there is a file in the archive, whether it is the latest n generation file, the case contains the following three records when storing the file:

(a) The URL of the archive (repository url): refers to the archive url stored in that entity.

(b) Node (file or folder): A relative path representing the file or folder under the first point.

(c) Revision: The version number in the physical archive.

In this case, the last transaction time recorded in S104 is firstly filtered out in all file storage records. Currently, those files have not existed due to the previous reconstruction; conversely, those records are still valid. Then in the other (relative to S204 In the archive of the current archive), can you find the same (b), if it is, the representative is the same file, and then compare (c), if it is the latest n generation file, it represents Must be retained. It can also be combined with the blacklist for further filtering to exclude collections of files that do not need to be retained.

These three parts of the file record are also used to deal with problems in file extraction. When the user needs to obtain a file, only by providing (b) and (c), the case can be obtained in the corresponding archive, and the extraction method is the same as the general archive. In addition to the Archives application, [File does not exist] and [Acquire files], the case also provides a status of [File Cleared] to distinguish the status of the file.

S207: Determine whether there is still an archive available for judgment. If yes, execute S204; if no, execute S209. This step is to compare the archive collections sorted by S202 and S205 one by one. If it is found that there is no comparison, the representative space is insufficient, and the flow goes to S209.

S208: Determine whether the space is sufficient to store the reserved software version file and submit the file. This step compares the currently reviewed archive with enough space to store the list of retained files from S206 and the set of files submitted by the user this time. If this archive list is generated by S205, then it is not necessary to consider submitting a file collection.

S209: The return does not have any archives with sufficient physical space to store. This step is to return the archives that are currently available. There is not enough space to store the submitted file collections while keeping the latest n-generation files.

S210: The result of the comparison is returned. The reserved file collection is temporarily stored in any scratch space. If there are reservations, there will be two return collections (a, b). a is the next time to return the reserved space The archive ID and the file to be retained are used by the main process S106. b is the return ID that will be used as the active archive for S105. If no reservation is performed, the return will be used as the ID of the active archive and the file to be retained for S105 and S106.

The invention further provides a computer program product for the file inventory control of the software version control. When the computer device loads and executes the computer program product, the steps described in the foregoing method can be completed.

The following will be described in the file inventory method of the present case, but the above-mentioned file inventory taking device 10 and the computer program product for file inventory can also achieve the following effects.

Set the version algebra to be retained to N generation, the total storage space is 300GB, and draw three archives A, B and C. The links (URLs) of each archive are shown in Table 1:

When there is a software version of the package file (devMBR.ear) waiting to be stored in the archive 13, the current active archive 13 is the archive A. Then, the file inventory taking device 10 queries the internal space of the archive A to be 200 MB, and the file of the package file is 800 MB. Therefore, it is necessary to select another archive 13 to store the package file.

Then, sorting is performed according to the last transaction time of the three archives 13 (from old to new), and a set [C, B, A] is generated. Then select the archive C to generate the archives retained by the archive C. set. And analyze the past execution records, compare each node record with http://10.144.97.99/repoA/ and http://10.144.97.99/repoB/, and find the latest 3 versions as stored in The node of archive 13C.

Then, through the last transaction time recorded in S104, in all the file storage records, those files have not existed due to the previous reconstruction; or, it is known that those records are still valid. Assuming that 530 records are still valid, they are filtered from 530 and filtered to represent those different nodes. Assume that 28 nodes are obtained, and these 28 nodes refer to the node paths in S206.

Then, the 28 nodes are compared to the valid storage records of the archive 13A and the archive 13B to determine whether the same node is stored in the archive 13A and the archive 13B.

Suppose that comparing the storage records of these 28 nodes, it is found that 25 nodes can find a total of three or more files in the archives A and B, representing the latest archive algebra that has met the minimum of the 25 nodes. 3 versions) requirements.

When software/fo/batch/encap.jar is only stored in a version of archive A, but archive B is not stored, and software/fo/batch/report.jar is in archive A and archive B, Each version is stored, and no A is found at the same time. The software/fo/batch/cypher.jar is stored in B.

So the following three files need to be retained

(1) software/fo/batch/cypher.jar (the latest 3 versions)

(2) software/fo/batch/encap.jar (latest 2, 3 version)

(3) software/fo/batch/report.jar (latest version 3)

These three files, a total of 6 files need to be retained (cypher.jar *3+ Encap.jar*2+report.jar*1)

In S208, the six files assume 30MB, plus 800MB of devMBR.ear, so the total space of the archive C is greater than 830MB. Suppose the archive C has 20GB. Then, the six files and their version numbers are returned to the archive C in S210.

Next, in S104, the archive 13C is deleted from the operating system layer, and the archive 13, the configuration authority, and the recording transaction time are regenerated. The active archive 13 is specified in S105, and the archive C is set as the active archive 13. The file collection to be retained is stored in S106. The above three files and six versions of the contents are checked into the archive 13C, and the last change time and the corresponding version number are recorded. The submitted file set is stored in the active archive 13 in S107.

Finally, save the submitted devMBR.ear to the archive 13C, and record the last transaction date and the corresponding version number.

The detailed description of the preferred embodiments of the present invention is intended to be limited to the scope of the invention, and is not intended to limit the scope of the invention. The patent scope of this case.

S101~S108‧‧‧Steps

Claims (8)

A file inventory taking device for software version control includes: receiving a software version file from an external file, and checking the software version file into one of the external plurality of archives, and storing the file in the active file library When the capacity exceeds the allowable storage amount, the access record time information according to each archive is the last transaction time, so as to select the archive that is successively checked in. The file inventory fetching device of claim 1, wherein the software version control is an Apache Subversion. The file inventory retrieval system of claim 1, wherein the software version file includes a binary file. The file inventory taking system of claim 1, wherein the access record time information is the last transaction time. A file inventory taking method for software version control, applied to a computer device, comprising the steps of: receiving a software version file from the outside; and checking the software version file into one of the external plurality of archives, and When the storage capacity of the archive exceeds the allowable storage amount, the access record time information of each archive is the last transaction time, so as to select the archive that is successively checked in. The file inventory taking method of claim 5, wherein the software version control adopts an Apache Subversion. The file inventory taking method of claim 5, wherein the software version file comprises a binary file. A file program for software version control to take computer program products, when the computer device is loaded And executing the computer program product, the method of any one of claims 5 to 7 can be completed.