CN109871233B

CN109871233B - Cloud programming file management method and device, equipment and storage medium

Info

Publication number: CN109871233B
Application number: CN201910116256.1A
Authority: CN
Inventors: 谭林丰; 陈宏君; 张磊; 文继峰; 顾熹; 曾凯; 刘坤; 徐睿; 沈刚
Original assignee: NR Electric Co Ltd; NR Engineering Co Ltd; State Grid Electric Power Research Institute
Current assignee: NR Electric Co Ltd; NR Engineering Co Ltd; State Grid Electric Power Research Institute
Priority date: 2019-02-13
Filing date: 2019-02-13
Publication date: 2022-05-17
Anticipated expiration: 2039-02-13
Also published as: CN109871233A

Abstract

The embodiment of the application discloses a cloud programming file management method, a cloud programming file management device, cloud programming file management equipment and a storage medium, wherein the method comprises the following steps: acquiring a project editing instruction, wherein the project editing instruction is used for representing a project of which a history version is checked out from a history library; determining a version identification of the project to be checked out according to the project editing instruction; copying a file of the project to be checked out into a newly-built real-time library according to the version identification of the project to be checked out; the real-time library is used for storing files of a project edited currently; acquiring a project filing instruction, wherein the project filing instruction carries a filed version identifier; determining the archived version identification as the version identification of the project edited currently in the real-time library; and storing the files of the project edited currently into a historical library corresponding to the real-time library.

Description

Cloud programming file management method and device, equipment and storage medium

Technical Field

The embodiment of the application relates to the technical field of file management, and relates to but is not limited to a cloud programming file management method, a cloud programming file management device, cloud programming file management equipment and a storage medium.

Background

At present, visual programming is widely applied in the fields of power systems, industrial control and the like. In the prior art, the visual programming environment is mostly a single-machine version, the problem of inconsistent compiling environment for multi-user development and use exists, multi-user development engineering is not supported, serial development or manual engineering combination is often needed, and the engineering development efficiency is influenced.

In order to improve the development efficiency of a multi-person development project, a visual programming method based on a cloud programming mode is needed, and a plurality of project versions can be formed in the process of the multi-person development project, so that the management of cloud programming files is challenged.

Disclosure of Invention

In view of this, embodiments of the present application provide a cloud programming file management method and apparatus, a device, and a storage medium to solve at least one problem in the prior art.

The technical scheme of the embodiment of the application is realized as follows:

in a first aspect, an embodiment of the present application provides a cloud programming file management method, where the method includes:

acquiring a project editing instruction, wherein the project editing instruction is used for representing a project of which a history version is checked out from a history library;

determining the version identification of the project to be checked out according to the project editing instruction;

copying the file of the project to be checked out to a newly-built real-time library according to the version identification of the project to be checked out; the real-time library is used for storing files of a project edited currently;

acquiring a project filing instruction, wherein the project filing instruction carries a filed version identifier;

determining the archived version identification as the version identification of the project edited currently in the real-time library;

and storing the files of the currently edited project into a historical library corresponding to the real-time library.

In a second aspect, an embodiment of the present application provides a cloud programming file management apparatus, where the apparatus includes:

the system comprises an editing instruction acquisition module, a history database acquisition module and a history database acquisition module, wherein the editing instruction acquisition module is used for acquiring a project editing instruction which is used for representing a project of which a history version is checked out from a history database;

the version identification determining module is used for determining the version identification of the project to be checked out according to the project editing instruction;

the sign-out module is used for copying the file of the project to be signed out into a newly-built real-time library according to the version identification of the project to be signed out; the real-time library is used for storing files of a project edited currently;

the system comprises a filing instruction acquisition module, a filing instruction acquisition module and a filing instruction processing module, wherein the filing instruction acquisition module is used for acquiring an engineering filing instruction which carries a filing version identifier;

the version identification adding module is used for determining the filed version identification as the version identification of the project edited currently in the real-time library;

and the storage module is used for storing the files of the currently edited project into a historical library corresponding to the real-time library.

In a third aspect, an embodiment of the present application provides a cloud programming file management device, where the device includes: the cloud programming file management system comprises a memory and a processor, wherein the memory stores a computer program capable of running on the processor, and the processor realizes the cloud programming file management method when executing the computer program.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium having stored therein computer-executable instructions configured to execute the cloud programming file management method.

Firstly, in the embodiment of the application, a cloud programming project is divided into a real-time library and a historical library for storage, the project edited currently is stored in the real-time library, and the project of a historical version is stored in the historical library; therefore, a user can file the project edited currently in the real-time library into the historical library through the project filing instruction to form a project with a historical version, and the historical version can be stored properly. Secondly, projects of different historical versions are distinguished through version identification, and the version identification is added to the project of each historical version during filing, so that a user can sign out a specific historical version through the version identification, and each historical version can be traced, thereby perfecting management of the historical version, and further improving the efficiency of multi-user engineering development.

Drawings

Fig. 1 is a schematic flow chart illustrating an implementation of a cloud programming file management method according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a cloud programming file storage architecture according to an embodiment of the present application;

FIG. 3 is a flowchart illustrating management of historical versions of cloud programming files according to an embodiment of the present disclosure;

fig. 4 is a schematic structural diagram illustrating a composition of a cloud programming file management apparatus according to an embodiment of the present application;

fig. 5 is a hardware entity diagram of a computer device according to an embodiment of the present application.

Detailed Description

In the visual programming operation, each user edits and saves the project file through client software to form a plurality of historical versions of the same project. When multiple persons jointly develop the project, the number of users is increased, and the historical version of the project is multiplied. Historical versions saved by multiple users in the engineering editing process need to be stored properly. In some cases, the user also needs to edit based on some historical version. When a project is developed by multiple persons, the storage requirements of a large number of historical versions and the tracing requirements of a specific historical version provide challenges for the management of the cloud programming files.

According to the embodiment of the application, the historical libraries corresponding to the real-time library are arranged to store the historical versions to meet the storage requirements of a large number of historical versions, and the version identification is arranged for each historical version to meet the tracing requirements of a specific historical version.

The technical solution of the present application is further elaborated below with reference to the drawings and the embodiments.

Example one

An embodiment of the present application provides a cloud programming file management method, as shown in fig. 1, the cloud programming file management method includes:

step S11, a project editing instruction is obtained, where the project editing instruction is used to characterize a project that has signed a history version out of a history library.

In the implementation process, the method is applied to computer equipment, such as electronic equipment with information processing capability, such as a notebook computer, a tablet computer, a desktop computer, a mobile phone and the like.

When implemented, the method may be implemented using client software, for example, a user may implement the steps of the method by installing and running the client software on a computer device. The client software is provided with a human-computer interaction interface and used for receiving user instructions, and a user accesses a database through the client software, wherein the database is used for storing cloud programming files of projects.

In an embodiment of the present application, the database includes a real-time library region and a historical library region. For a particular project, the files contained in the currently edited version are stored in the live repository, and the files contained in the version archived at the historical time are stored in the historical repository corresponding to the live repository. The set of files in the real-time library is the project edited currently, and the set of files in the history library is the history version of the project.

Under the condition that a project is developed by multiple persons, each user can access the database through client software, a certain historical version of the project in the historical library is copied into a newly-built real-time library, editing is carried out on the basis of the historical version, the operation is sign-out, and the historical version of the project is the project to be signed out.

In order to sign out a project of a certain historical version, a user needs to send out a project editing instruction. The human-computer interaction interface of the client software is provided with an engineering editing button, a user selects the engineering editing button, and the computer equipment obtains an engineering editing instruction. In other embodiments, the user may enter engineering editing instructions at a human-machine interface of the client software.

And step S12, determining the version identification of the project to be checked out according to the project editing instruction.

In order to manage large-scale historical versions in order to meet the tracing requirement of a specific historical version, version identification is set in the embodiment of the application to distinguish different historical versions. The version identification is used for representing the sequence of filing the historical versions of the project into the history library, and can be a version number or a time stamp.

In some embodiments, the project editing instruction is used to invoke a sub-menu for a user to select a history version, and the version identifier corresponding to the history version selected by the user is the version identifier of the project to be checked out.

Here, in response to a project editing instruction triggered by the user selecting a project editing button, the computer device may further provide the user with a sub-menu in which respective historical versions of the project requiring operation are listed for selection by the user. When the user selects a specific historical version, namely, the project indicating that the user wishes to sign out the specific historical version, the computer device can extract the version identifier corresponding to the historical version according to the operation of the user.

In other embodiments, the project editing instruction carries the version identifier of the project to be checked out.

The project editing instruction input by the user on the human-computer interaction interface comprises a project version identification which the user wants to sign out, and the computer equipment acquires the version identification from the project editing instruction and determines the version identification as the project version identification to be signed out.

Step S13, copying the file of the project to be signed out to a newly-built real-time library according to the version identification of the project to be signed out; the real-time library is used for storing files of a project edited currently.

Generally, the project to be checked out is stored in the history database and is a certain history version of the project currently edited in the real-time database, and the version identification is convenient for the user to find a specific history version.

After the version identification of the project to be checked out is determined, the computer equipment copies the project file corresponding to the version identification in the historical library to a newly-built real-time library according to the version identification, so that a user can edit the project based on the historical version, and the historical version can be traced.

In this embodiment, a new branch starting point is formed for the project to be checked out copied to the newly-built real-time library, which is opposite to the original historical version sequence of the project, so that the user can modify, edit and archive the project by using the historical version as the starting point to form a new historical version sequence.

And step S14, acquiring a project filing instruction, wherein the project filing instruction carries a filing version identifier.

When the project is edited in the real-time library, a user can store the currently edited project into the historical library according to requirements to form a project with a historical version, and the operation is filing. Through the filing operation, under the condition of multi-person engineering development, each user can store own version in the history library, and the perfect management of the history version is realized.

In this embodiment, the engineering filing instruction carries the filed version identifier, and the filed version identifier may be obtained from the user by using the same method as the engineering editing instruction.

Step S15, determining the archived version identification as the version identification of the project edited currently in the real-time library.

Generally, before storing a file of a project currently edited in a real-time library into a history library, an archived version identifier needs to be determined as a version identifier of the project, so as to realize ordered management of history versions.

In some embodiments, the version identification may be a version number, and the filename of the file to be archived is modified to include the version number, or the version number is added to the file to be archived, so that the archived version identification is determined to be the version identification of the project currently edited in the live library. In other embodiments, the version identification may be the time of filing, i.e. the time stamp of filing, and the time stamp of filing is added to the file to be filed, so that the filed version identification is determined as the version identification of the project currently edited in the live library.

And step S16, storing the files of the project edited currently into a history library corresponding to the real-time library.

The method and the system realize the filing operation of the project edited currently in the real-time library by adding the version identification in the project file edited currently and storing the files into the history library corresponding to the real-time library.

In addition, when the user edits the project in the real-time library, the project can be stored at any time to keep the progress. In this case, the currently edited project file is temporarily stored in the live repository and is not archived as a historical version in the historical repository.

In the embodiment of the application, the version identification is used as an index, and the project edited currently in the real-time library is filed in the historical library, so that the historical version of the cloud programming file is perfectly managed, and the efficiency of developing the project by multiple persons is improved.

Example two

The embodiment of the application provides a cloud programming file management method, which comprises the following steps:

step S201, a project editing instruction is obtained, where the project editing instruction is used to represent a project of which a history version is checked out from a history library.

And step S202, determining the version identification of the project to be checked out according to the project editing instruction.

Step S203, copying the file of the project to be signed out to a newly-built real-time library according to the version identification of the project to be signed out; the real-time library is used for storing files of a project edited currently.

Step S204, acquiring a project filing instruction, wherein the project filing instruction carries a filing version identifier.

Step S205, determining the archived version identification as the version identification of the project edited currently in the real-time library.

Step S206, if the project edited currently is filed for the first time, a historical library corresponding to the real-time library is newly built, the file of the project edited currently is stored in the newly built historical library, and a historical version filed for the first time of the project edited currently is formed.

Step S207, if the currently edited project is not archived for the first time, storing the file of the currently edited project into the history library corresponding to the real-time library to form a latest archived history version of the currently edited project.

And in the history library, all history versions of the currently edited project are sequentially stored according to the filing sequence to form a linear version tree.

Here, steps S206 and S207 provide a way to implement step S16. In this way, when a project currently edited in the real-time library is archived, it may be the first archiving operation that occurs to the project, and in this case, a history library corresponding to the real-time library needs to be newly created to store the history version of the project currently edited. And storing the files of the project edited currently into the historical library, namely forming a historical version of the first archive of the project.

If the project currently edited in the live library is not archived for the first time, the historical library corresponding to the live library already exists, and a plurality of historical versions of the project are stored in the historical library. The files of the project edited currently are stored in the history library, namely the latest archived history version of the project is formed.

In the historical library, all historical versions of a project edited at present are sequentially stored according to an archiving sequence, an archiving time is taken as a clue, each archiving time forms a node, a linear version tree is formed by the historical versions stored sequentially in a linear structure corresponding to one historical version.

And generating a new real-time library each time one of the historical versions in the historical library is checked out in response to the engineering editing instruction, wherein the new real-time library also corresponds to a new historical library. Thus, the process creates a new branch. For a specific project, each branch adopts a linear mode to store history versions, and the history versions are not mutually covered.

EXAMPLE III

step S301, a project editing instruction is obtained, wherein the project editing instruction is used for representing a project of which a history version is checked out from a history library.

And step S302, determining the version identification of the project to be checked out according to the project editing instruction.

Step S303, copying the file of the project to be signed out to a newly-built real-time library according to the version identification of the project to be signed out; the real-time library is used for storing files of a project edited currently.

Step S304, acquiring a project filing instruction, wherein the project filing instruction carries a filing version identifier.

Step S305, determining the archived version identification as the version identification of the project edited currently in the real-time library.

And S306, classifying the files of the currently edited project according to the file types of the files, and respectively storing the classified files into different areas of the historical library corresponding to the real-time library.

Here, step S306 provides a manner of implementing step S16, in which the files of the project currently edited are classified according to the file types, the storage areas of the files of different types are divided according to the file types, and the files of different types are stored in different areas of the history library corresponding to the real-time library.

In order to improve the efficiency of data query, files of the same type are stored in the same area, so that the data are more concentrated. When data is inquired, the required disk seek operation is less, and the efficiency is higher.

Generally, a user can divide the file types of files according to the query habits of the user or the attributes of projects. In some embodiments, the files may be divided into entity files containing entity content data and directory files containing storage location data of the entity files. In other embodiments, the file types may also be divided into high-frequency query files and low-frequency query files according to the queried frequency; or dividing the file types into high-frequency editing files and low-frequency editing files according to the frequency of modification and editing; or the file types are divided according to the importance degree of the contents stored in the files, and the files are divided into important files and general important files.

Example four

step S401, a project editing instruction is obtained, wherein the project editing instruction is used for representing a project of which a history version is checked out from a history library.

And S402, determining the version identification of the project to be checked out according to the project editing instruction.

Step S403, copying the file of the project to be checked out to a newly-built real-time library according to the version identification of the project to be checked out; the real-time library is used for storing files of a project edited currently.

And S404, acquiring a project filing instruction, wherein the project filing instruction carries a filed version identifier.

Step S405, determining the archived version identification as the version identification of the project edited currently in the real-time library.

Step S406, dividing the currently edited file of the project into a first entity file and a first directory file according to the file type of the file.

Step S407, storing the first entity file in an entity data area of the history repository.

Step S408, storing the first directory file in a directory information area of the history repository.

The entity file is a file containing entity content data, and the directory file is a file containing storage location data of the entity file.

Here, step S406, step S407, and step S408 provide a manner of implementing step S306, in which there are two types of files in the live library, one is an entity file containing entity content data, and the other is a directory file containing storage location data of the entity file.

When a history version of a project needs to be checked out from a history library, firstly all directory files corresponding to the version identification are copied to a newly-built real-time library from a directory information area of the history library, then all entity files corresponding to the directory files are obtained by inquiring according to storage position data of the entity files stored in the directory files, and the entity files are copied to the same newly-built real-time library. Thus, the sign-out operation of a project can be completed.

In some embodiments, the data store is implemented using a non-relational database. In a non-relational database, a key-value (key-value) is adopted to store a structure, so that an index can be created, and efficient search is realized.

Taking the MongoDB database as an example, the first entity files stored in the entity data area of the historical library form a set, and the first directory files stored in the directory information area form a set. Each first entity file is a document, and each first directory file is also a document.

In MongoDB, each stored document has a 'id' key corresponding to a unique 'id' value, so that each document in a set can be uniquely identified. Directory files may establish relationships by referencing the "_ id" key of an entity file. After a user inquires a specific directory file, the cited entity file can be inquired through the 'id' key of the entity file cited by the directory file, and then the value corresponding to the key is obtained by inquiring the specific key in the cited entity file.

In addition to the "_ id" key, the user can add other keys to the document by himself and assign corresponding values to each key to implement data storage. Specifically, one entity file may include a "doc" key and an "fname" key, where a value corresponding to the "doc" key is a binary content of the entity file, so as to implement storage of a specific entity content of a project; the value corresponding to the 'fname' key is the file name of the entity file, the file name can also identify the entity file, and compared with the 'id' key, the identification method is more in line with the habitual thinking of the user.

A directory file can contain a "dname" key, a "dir" key, a "sdirs" key and a "profiles" key, wherein a value corresponding to the "dname" key represents the name of the directory file and is used for simulating the file system structure of a file resource manager in a windows system, and a value corresponding to the "dname" key is equivalent to the file name of the folder. Accordingly, the value corresponding to the "dir" key represents the absolute path of the folder in the file system, the value corresponding to the "sdirs" key represents the information such as the "_ id" key, the name and the storage path of the subfolder contained in the folder, and the value corresponding to the "sfiles" key represents the information such as the "_ id" key and the file name of the entity file contained in the folder. Thus, the storage path represented by the "dir" key value of the directory file and the folder name corresponding to the "dname" key of the directory file are the storage locations of the entity files cited in the "sfiles" key, and the information contained in all directory files corresponding to one version identifier in the directory information area can show the complete hierarchical structure of the project corresponding to the version identifier.

In order to enable the information contained in the directory file to correctly show the complete hierarchical structure of the project corresponding to the version identifier, the information of the directory file to be archived needs to be updated according to the entity file to be archived during archiving. The updated directory file is the directory file corresponding to the archived version identifier and is stored in the directory information area of the history library. In the directory information area of the historical library, each historical version has a set of directory files corresponding to each historical version so as to record the hierarchical structure of the content in each version.

In some embodiments, the project currently edited in the live library is newly created, and the user can write the name and storage path of the entity file, the name and storage path of the folder, the reference relationship of the folder to the child folder and the entity file, and the like according to the user's own plan for the hierarchical structure of the project. When the project is filed, the directory file can be directly stored without special modification.

EXAMPLE five

step S501, a project editing instruction is obtained, and the project editing instruction is used for representing a project of which a history version is checked out from a history library.

And step S502, determining the version identification of the project to be checked out according to the project editing instruction.

Step S503, copying the file of the project to be signed out to a newly-built real-time library according to the version identification of the project to be signed out; the real-time library is used for storing files of a project edited currently.

Step S504, a project filing instruction is obtained, and the project filing instruction carries a filing version identifier.

And step S505, determining the archived version identification as the version identification of the project edited currently in the real-time library.

Step S506, according to the file type of the file, dividing the file of the currently edited project into a first entity file and a first directory file.

Step S507, storing the first entity file in an entity data area of the history repository.

Step S508, storing the first directory file in a directory information area of the history repository.

In step S509, an information recording file is newly created in the information recording area of the history repository.

Step S510, recording the name of the first entity file, the storage location data of the first entity file, and the archived version identifier in the information recording file.

Step S511, storing the information recording file in an information recording area of the history repository.

Here, step S509, step S510, and step S511 are for recording filing information of a project when the project currently edited in the live library is filed, in which one information recording area is divided in the history library, and an information recording file for each filing operation is stored in this area.

Each historical version of the project in the historical library has a corresponding information recording file, in order to distinguish the information recording files of different historical versions, an archived version identifier needs to be recorded in the information recording file, and the method in the first embodiment may be adopted to add the version identifier in the information recording file.

The name of the first entity file and the storage position of the first entity file can represent the hierarchy of the effective content of a project, and the information is stored in the information recording file, so that the entity files can be included and the hierarchy of the entity files can be stored when the project is archived.

EXAMPLE six

step S601, a project editing instruction is obtained, wherein the project editing instruction is used for representing a project of which a history version is checked out from a history library.

And step S602, determining the version identification of the project to be checked out according to the project editing instruction.

Step S603, copying the file of the project to be signed out to a newly-built real-time library according to the version identification of the project to be signed out; the real-time library is used for storing files of a project edited currently.

Step S604, acquiring a project filing instruction, wherein the project filing instruction carries a filing version identifier.

Step S605, determining the archived version identifier as the version identifier of the currently edited project in the real-time library.

Step S606, according to the file type of the file, dividing the file of the currently edited project into a first entity file and a first directory file.

Step S607, acquiring a second entity file; and the second entity file is the entity file corresponding to the latest archived historical version of the project.

Step S608, comparing the first entity file with the second entity file to obtain a third entity file; the third entity file comprises an entity file updated by the first entity file compared with the second entity file and a newly added entity file.

Step S609, store the third entity file in the entity data area of the history repository.

Step S610, storing the first directory file in a directory information area of the history repository.

Here, step S607, step S608 and step S609 provide a way to implement step S407, in which to avoid redundant storage of files, an incremental update policy is used for entity file storage. In the mode of incremental updating, only the entity files of the project which needs to be archived and the newly archived entity files of which the historical version is updated relative to the latest archived version in the historical library are stored in the historical library during archiving.

For a project needing to be filed, an entity file corresponding to a latest filed historical version of the project is obtained and recorded as a second entity file. And comparing the first entity file of the project edited currently with the second entity file to obtain an updated entity file and a newly added entity file of the first entity file compared with the second entity file, and recording as a third entity file. The third entity file is then stored in the entity data area of the historian. The third entity files contain archived version identifiers, and the method for adding the version identifiers is the same as that described in the first embodiment.

When the updated entity file is stored in the entity data area of the historical library, the updated entity file is stored as a new entity file, and the original entity file corresponding to the updated entity file is not covered, so that the complete management of each historical version is realized, and the phenomenon that the previous historical version is covered and necessary information is lost is avoided.

The part of the first entity file, which is not the third entity file, comprises an entity file which needs to be archived and a deleted entity file, wherein the entity file is kept unchanged relative to the latest archived historical version of the project.

For the entity file deleted in the project edited currently, the entity file is stored in the entity data area of the historical library at the last archiving time, and the contained version identification is the version identification of the last archiving. When searching according to the currently filed version identification, the deleted entity files are not related.

For entity files that remain unchanged in the currently edited project, which were stored in the entity data area of the historian at the last archiving time, the contained version identification is the version identification of the last archiving. When the current archive operation is executed, the version identification of the current archive is added to the entity files. Therefore, when searching is carried out according to the version identification filed currently and the version identification filed last time, the entity files which are kept unchanged can be associated.

In some embodiments, both entity files and directory files are stored in a MongoDB database. Directory files implement references to entity files via the "sfiles" key. For a particular entity file, the entity file may be contained in several historical versions of the project, each of which contains a directory file that references the entity file. In order to represent the association relationship between a specific entity file and each version of a project, a "refs" key may be set in the entity file, and the numerical value corresponding to the "refs" key is the number of versions containing the entity file. In addition, the reference of the project being edited in the real-time library to the entity file is also marked as a reference.

Thus, when a history version of a project is checked out from the history library, 1 needs to be added to the value corresponding to the "refs" key of each entity file. When the third entity file is stored in the entity data area of the historical library, the value corresponding to the 'refs' key of the files is 1, the value corresponding to the 'refs' key of the deleted entity file needs to be reduced by 1 when the deleted entity file is archived, and the value corresponding to the refs key of the unchanged entity file is maintained unchanged when the entity file is archived.

EXAMPLE seven

step S701, a project editing instruction is obtained, and the project editing instruction is used for representing a project of which a history version is checked out from a history library.

And step S702, determining the version identification of the project to be checked out according to the project editing instruction.

Step S703, copying the file of the project to be signed out to a newly-built real-time library according to the version identification of the project to be signed out; the real-time library is used for storing files of a project edited currently.

Step S704, a project filing instruction is obtained, and the project filing instruction carries a filing version identifier.

Step S705, determining the archived version identifier as the version identifier of the project currently edited in the live library.

Step S706, according to the file type of the file, dividing the file of the currently edited project into a first entity file and a first directory file.

Step S707, store the first entity file in an entity data area of the history repository.

Step S708, storing the first directory file in a directory information area of the history repository.

In step S709, an information recording file is newly created in the information recording area of the history repository.

Step S710, acquiring a fourth entity file; and the fourth entity file is the entity file corresponding to the latest archived historical version of the project.

Step S711, comparing the first entity file with the fourth entity file to obtain a fifth entity file, where the fifth entity file includes an updated entity file, a newly added entity file, and a deleted entity file of the first entity file as compared with the fourth entity file.

Step S712 records the name of the fifth volume file, the storage location data of the fifth volume file, and the archived version id in the information recording file.

Step S713, the information recording file is stored in the information recording area of the history repository.

Here, step S710, step S711, and step S712 provide a way to implement step S510, in which an information recording file is newly created in the information recording area of the history repository, and the filing information of the project is recorded in the information recording file.

In the incremental update mode, the archive information of the information record file record may include only the changed entity files. Specifically, for a project needing to be archived, an entity file corresponding to a latest archived historical version of the project is first acquired and recorded as a fourth entity file. And comparing the first entity file of the project edited currently with the fourth entity file to obtain an updated entity file, a newly added entity file and a deleted entity file of the first entity file compared with the fourth entity file, and marking as a fifth entity file. The name of the fifth volume file, the storage location data of the fifth volume file, and the archived version identification are then recorded in this information recording file.

Based on the information recorded in the information recording file, the hierarchical structure of the project filed this time can be obtained by combining the directory file corresponding to the latest filed historical version. In addition, the hierarchical structure of the project to be archived can also be obtained through a directory file. In order to enable the information contained in the directory file to correctly show the complete hierarchical structure of the project corresponding to the version identifier, the information of the directory file to be archived needs to be updated according to the entity file to be archived during archiving. By comparing the hierarchical structure obtained based on the information recording file with the hierarchical structure obtained based on the directory file, it is possible to determine whether or not the information in the information recording file or the directory file filed this time is erroneous.

Example eight

step S801, a project editing instruction is obtained, where the project editing instruction is used to represent a project of which a history version is checked out from a history library.

And S802, determining the version identification of the project to be checked out according to the project editing instruction.

And S803, searching the files belonging to the project to be signed out according to the version identification of the project to be signed out. The real-time library is used for storing files of a project edited currently.

Step S804, classifying the files of the project to be signed out according to the file types of the files, and acquiring a fifth body file and a fifth directory file of the project to be signed out.

Step S805, copying the fifth volume file into the entity data area of the newly created live library.

Step S806, copy the fifth directory file to the directory information area of the newly created live library.

Step S807, a project filing instruction is obtained, wherein the project filing instruction carries a filing version identifier.

Step S808, determining the archived version identifier as the version identifier of the currently edited project in the real-time library.

And step S809, storing the files of the currently edited project into a historical library corresponding to the real-time library.

Here, step S803, step S804, step S805, and step S806 provide a way to implement step S13, in which, in order to improve the efficiency of data query in the live library, the live library is also divided into different areas, and files of the same type are stored in the same area. For example, the entity file checked out from the history repository is copied into the entity data area, and the directory file checked out from the history repository is copied into the directory information area.

Example nine

step S901, a project editing instruction is obtained, where the project editing instruction is used to represent a project of signing out a history version from a history library.

And S902, determining the version identification of the project to be checked out according to the project editing instruction.

Step S903, copying the file of the project to be signed out to a newly-built real-time library according to the version identification of the project to be signed out; the real-time library is used for storing files of a project edited currently.

In step S904, a file lock instruction is acquired.

Step S905, according to the file locking instruction, modifying the locking state of the corresponding file in the real-time library; the locked state characterizes that the file only allows editing operations by a single user.

Step S906, acquiring a project filing instruction, wherein the project filing instruction carries a filing version identifier.

Step S907, determine the archived version identifier as the version identifier of the project currently edited in the real-time library.

Step S908, storing the file of the currently edited project into the history library corresponding to the real-time library.

Here, step S904 and step S905 allow the user of the multi-person development project to lock the file. When a project is developed by multiple users, in order to prevent a plurality of users from performing conflicting operations on a specific file, the current user can lock the file in the real-time library, and prevent other users from changing the content of the file. In some embodiments, a "locked" key may be set in the entity file and the directory file, and the lock state of the file may be modified by setting a value corresponding to the "locked" key. When the key value is 1, the file is locked and can only be edited by the current user, the authority of other users only has browsing, and when the key value is 0, the file is unlocked and can be edited by other users.

Example ten

The embodiment of the application further provides a cloud programming file storage method, which can realize efficient storage and perfect version management of a cloud programming file system and meet the application requirement that storage and historical versions are traceable in distributed cloud programming. The method specifically comprises the following steps:

step S1001, designing a cloud programming file storage architecture. As shown in fig. 2, the cloud programming project is divided into real-time library and historian storage. The real-time library is used for storing currently edited project files, the real-time library is divided into two sets, a set A in the entity data area is used for storing entity files, and binary contents are stored in the entity files; the set B in the directory information area stores directory files, which are documents describing hierarchical directories. Different projects name set A and set B by their respective project names. The historical library is used for filing or signing out a real-time library file with a certain version identifier, wherein the version identifier can be a filing time stamp, and the historical library adopts a linear version tree structure and an entity file increment updating strategy.

And step S1002, selecting the database. Both the live library and the historical library use non-relational databases, and in some embodiments, a mongoDB database may be used.

MongoDB is a database with superior performance. Documents are the core concept of MongoDB, which is the fundamental unit of data, similar to a row in a relational database. In MongoDB, a document is represented as an ordered set of key-value pairs. The representation of the document is typically tagged using json-like bson format, as follows:

{"title":"hello！",

"recommend":5,

"author":"paul"}

the data types supported by the key values of the document comprise NULL, Boolean, numerical values, character strings, arrays, embedded documents, dates, regular expressions, binary data and the like.

A collection is a set of documents, equivalent to a data table in a relational database. The set is in a dynamic mode, specifically, documents in a set can be various, but the documents of the same type are placed in a set, so that the data is more concentrated, and when the data is queried, the required disk seek operation is less, and the efficiency is higher.

And step S1003, designing a set A and a set B in the real-time library.

The set A is used for storing binary entity files of a project, and a single entity file can comprise the following attributes:

an "_ id" key whose key value is the unique identification field of this file, which is the unique identification string of the file).

And the key value corresponding to the key is the file name of the file. To add version identification to the file, the version identification can be implemented by adding a version number after the file name as a suffix, so that when the entity file which is newly created and updated in each version is stored in the history library, the filed version number is added to the file. In the mode of incremental update, for a certain entity file belonging to a plurality of historical versions, the version number stored in the file name of the certain entity file is the version number corresponding to the certain entity file when the certain entity file is archived for the first time, and then the archived historical versions establish association with the entity file by referencing the 'id' key of the archived historical versions, wherein the number of the association can be embodied by the 'refs' key value in the entity file.

And a version key, wherein a key value corresponding to the version key is the version identification of the file. In order to add version identification to the file, a version number or an archived timestamp may be added to a key value of a "version" key, and for an entity file belonging to a plurality of historical versions, the key value of the "version" key includes a specimen number or an archived timestamp of each historical version. Referring to fig. 2, the timestamp may be T_nTime, T_n-1Time, T_nTime, T_n-1' time … ….

And a key value corresponding to the key is binary data of the file.

And an mtime key, wherein a key value corresponding to the mtime key is the latest modification time of the file.

The key value of the "muser" key is the user who modified the file last time.

And a locked key, wherein a key value corresponding to the locked key is used for representing whether the file is locked, and a user can prevent other users from modifying the content of the file by locking the file.

And a key value corresponding to the key is the number of the engineering versions containing the entity file. As shown in FIG. 2, T_nDirectory files archived at a time may reference T_nTime, T_n-1Time, T_n-2The entity file of the moment. The setting method is the same as that described in example six.

And an "MD 5" key, wherein a key value corresponding to the key is the MD5 check code information of the binary content of the current file.

As an example, the files in the live library collection A may be represented in the form:

{

_id:ObjectId(),

fname:“ABZ_PRE_V1.ghcx”,

doc:2018-07-26-12:53:06.267,

mtime:“214141489769”,

muser:“tanll”,

refs:1,

md5:“asdfafwaf”

}

set B is used to store the directory files of the project, and a single directory file may include the following attributes:

And a key value corresponding to the 'dname' key is the file name of the file, and is used for simulating the file system structure of the file resource manager in the windows system, and the key value is the file name of the folder. In order to add the version identifier, the version identifier can be added after the file name as a suffix, so that when the project in the real-time library is archived, the currently archived version number is used for replacing the last version number to form a directory file corresponding to the currently archived version number.

And a version key, wherein a key value corresponding to the version key is the version identification of the file. Its function is the same as the "version" key in the entity file.

And a dir key, wherein the key value corresponding to the dir key is used for representing the absolute path of the folder in the file system.

And the key value corresponding to the key is used for representing information such as an 'id' key, a name, a storage path and the like of the subfolder contained in the folder.

And a key value corresponding to the "sfiles" key is used for representing information such as an "_ id" key and a file name of the entity file contained in the folder.

And a 'muser' key, wherein a key value corresponding to the key is the user who modifies the file for the last time.

And a key value corresponding to the key is the user for locking the file.

And a key value corresponding to the key is used for representing a group name array formed by all the user groups of the file, and the key value is an authority group. The authority control of the file access operation can be performed through the authority group where the user name is located, and the authority corresponding to the authority group is specifically set by a 'perm' key value.

The key value of the 'perm' key is a three-digit character, the first character is used for representing the authority of a user for creating the file, the second character is used for representing the authority of the user contained in the 'group' key value, and the third character is used for representing the authority of other users. The file access operation authority comprises browsing, editing, locking and unlocking.

As an example, the files in the live library set B may be represented in the form:

thus, the directory file corresponds to a folder name pj1, the storage path is root, the referenced sub-folder name is temp, and the name of the entity file contained therein is ABZ _ pre. Based on this, the storage location of the entity file can be determined to be root/pj 1.

Step S1004, a history library structure is designed. The historical library is expanded based on an entity data area and an engineering directory information area of the real-time library, version saving and submission of visual project configuration files and program files are achieved, functions of searching and inquiring historical versions, signing out historical versions to the real-time library and the like are provided. The basic flow of version management is shown in fig. 3, and version management is managed based on a linear version tree.

For the project 1 currently edited in the live library 1, the project 1 can be stored in the live library 1 at any time. The timestamp of the first filing of the project 1 is xxx1, and a historical version 1 of the project 1 is formed in the corresponding historical library 1; the timestamp of the second archive is xxx2, and a historical version 2 of project 1 is formed in the history base 1; the timestamp of the third archive is xxx3, forming historical version 3 of project 1 in historian 1. If the user selects to sign out the historical version 2 from the historical library 1, the timestamp signed out by the historical version 2 is xxx4, and the historical version 2 is copied into the real-time library 2 to form a project 2. Project 2 was first archived with a timestamp xxx5, forming historical version 1 of project 2 in the corresponding historian 2. The next time a project 2 is archived, a historical version 2 of the project 2 is formed in the corresponding historian 2.

Based on this, the embodiment of the application meets the application requirements of real-time storage and historical version traceability of distributed cloud programming.

As shown in fig. 3, when the version is archived based on the live library 1 at the current time, the archived timestamp is xxx4, and the updated file, the deleted file, and the added file can be obtained by comparing the current project 1 of the live library 1 with the historical version 3 corresponding to the timestamp xxx3 in the historical library 1.

When editing needs to be performed based on a certain historical version, such as the historical version 2, in the historical library 1, the historical version 2 can be returned to a new real-time library 2 for editing, and the version tree of the historical library 2 is also a new linear version tree, namely a new branch.

Corresponding to projects in a real-time library, three corresponding sets exist in a historical library, and the three sets are respectively as follows:

and the set history _ set is positioned in the information recording area and stores the names and the storage position data of the updated entity file, the newly added entity file and the deleted entity file during each version filing.

A set dir _ set, which is located in a directory information area of the history library and stores directory files of each history version of the project; the file format and structure are the same as in the live library.

A set bin _ set, wherein the set is located in an entity data area of the historical library and stores updated entity files containing binary contents, which are newly added when each historical version of the project is archived; the entity file document format is the same as in the real-time library. When a project edited at present is filed, if an entity file is updated or newly added, an entity file is newly established, and a refs key value of the file is set as 1; if an entity file which is not updated is submitted, the refs key value of the file is kept unchanged; if the entity file is deleted, subtracting 1 from the 'refs' key value of the file; if a historical version is checked out from the historian, 1 is added to the "refs" key for each physical file in the version.

In order to record the corresponding relationship between the storage paths in the real-time library and the history library, the recording can be performed through a file in the set bash _ cfg, and the format of the file is as follows:

{

_id:“23rwefreg43”,

srcid:“q5gdfsby5u”,

dest:“root/hvdc/wdd”

}

the key value corresponding to the _idkey is the unique identifier of the file, the file refers to the unique identifier of a certain directory file in the real-time library through the srcid key, and the prefix of the directory file in the historical library is set through the dest key. Thus, the storage path of the corresponding folder in the history library is the prefix plus the storage path of the corresponding file in the real-time library.

Step S1005, developing client software. A user can access the database through the client software, create or open a project, and display a visual page on the client software. And after modification, submitting the project file to a real-time library when clicking to save. And the user performs locking/unlocking operations on the directory file and the entity file through client software. When the real-time library engineering section at a certain moment needs to be filed, the filing operation is triggered at client software, and the engineering of the real-time library is filed to the historical library according to the increment updating strategy to form a linear version tree.

In the embodiment of the application, the client can instantly access the cloud programming file through the real-time library, and the entity file and the directory file are stored by adopting the non-relational database, so that the consistency of the file operation efficiency and the single-machine version efficiency of the client is ensured, and the user experience is not influenced. Through the cloud programming engineering that the historical library can manage a plurality of versions, one of the historical versions can be selected to create a new branch for maintenance. And an increment updating strategy is adopted, so that redundant storage of the file is avoided. And the development of multiple persons is supported through the directory file lock. By adopting any one of the methods, the development efficiency of the user team of the visual programming can be improved.

EXAMPLE eleven

Based on the foregoing embodiments, an embodiment of the present application provides a cloud programming file management apparatus, where the apparatus includes modules that can be implemented by a processor in a computer device; of course, the implementation can also be realized through a specific logic circuit; in implementation, the processor may be a Central Processing Unit (CPU), a Microprocessor (MPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), or the like.

Fig. 4 is a schematic structural diagram of a cloud programming file management apparatus according to an embodiment of the present application, and as shown in fig. 4, the cloud programming file management apparatus 400 includes an editing instruction obtaining module 401, a version identifier confirming module 402, a sign-out module 403, an archiving instruction obtaining module 404, a version identifier adding module 405, and a storage module 406, where:

an edit instruction obtaining module 401, configured to obtain a project edit instruction, where the project edit instruction is used to represent a project of which a history version is checked out from a history library;

a version identifier determining module 402, configured to determine a version identifier of the project to be checked out according to the project editing instruction;

the sign-out module 403 is configured to copy the file of the project to be signed out to a newly-built real-time library according to the version identifier of the project to be signed out; the real-time library is used for storing files of a project edited currently;

a filing instruction obtaining module 404, configured to obtain an engineering filing instruction, where the engineering filing instruction carries a filing version identifier;

a version identifier adding module 405, configured to determine the archived version identifier as a version identifier of a currently edited project in the live library;

a storage module 406, configured to store the file of the currently edited project into a history library corresponding to the real-time library.

In some embodiments, the storage module comprises:

the first storage unit is used for establishing a new historical library corresponding to the real-time library if the project edited at present is filed for the first time; storing the files of the project edited currently into the newly-built historical library to form a historical version of the project edited currently and filed for the first time;

the second storage unit is used for storing the file of the project edited currently into the historical library corresponding to the real-time library to form a latest filed historical version of the project edited currently if the project edited currently is not filed for the first time; in the historical library, all the historical versions of the currently edited project are sequentially stored according to the filing sequence to form a linear version tree.

In some embodiments, the storage module comprises:

the first classification unit is used for classifying the files of the project edited currently according to the file types of the files;

and the third storage unit is used for respectively storing the classified files into different areas of the historical library corresponding to the real-time library.

In some embodiments, the file types include entity files and directory files, wherein: the entity file is a file containing entity content data, and the directory file is a file containing storage location data of the entity file.

In some embodiments, the storage module comprises:

the second classification unit is used for classifying the files of the currently edited project into a first entity file and a first directory file according to the file types of the files;

a fourth storage unit, configured to store the first entity file in an entity data area of the history repository;

a fifth storage unit, configured to store the first directory file in a directory information area of the history repository.

In some embodiments, the cloud programming file management apparatus further includes an information recording module, the information recording module including:

an information creating unit for creating an information recording file in an information recording area of the history library;

a first recording unit, configured to record a name of the first entity file, storage location data of the first entity file, and the archived version identifier in the information recording file;

a sixth storage unit that stores the information recording file in an information recording area of the history repository.

In some embodiments, the storage module comprises:

a first obtaining unit, configured to obtain a second entity file; the second entity file is an entity file corresponding to the latest archived historical version of the project;

the first comparison unit is used for comparing the first entity file with the second entity file to obtain a third entity file; the third entity file comprises an entity file updated by the first entity file compared with the second entity file and an added entity file;

a seventh storage unit, configured to store the third entity file in an entity data area of the history repository.

In some embodiments, the information recording module comprises:

a second obtaining unit, configured to obtain a fourth entity file; the fourth entity file is an entity file corresponding to the latest archived historical version of the project;

a second comparing unit, configured to compare the first entity file with the fourth entity file to obtain a fifth entity file, where the fifth entity file includes an updated entity file, a newly added entity file, and a deleted entity file of the first entity file compared with the fourth entity file;

and a second recording unit configured to record a name of the fifth volume file, storage location data of the fifth volume file, and the archived version id in the information recording file.

In some embodiments, the check-out module comprises:

the searching unit is used for searching files belonging to the project to be signed out according to the version identification of the project to be signed out;

the third classification unit is used for classifying the files of the project to be checked out according to the file types of the files;

and the first copying unit is used for copying the classified files to different areas of the newly-built real-time library respectively.

In some embodiments, the check-out module comprises:

the fourth classification unit is used for classifying the files of the project to be signed out according to the file types of the files to obtain a fifth volume file and a fifth directory file of the project to be signed out;

the second copying unit is used for copying the fifth volume file into the entity data area of the newly-built real-time library;

and the third copying unit is used for copying the fifth directory file into the directory information area of the newly-built real-time library.

In some embodiments, the cloud programming file management apparatus further comprises a locking module, the locking module comprising:

a lock instruction acquisition unit for acquiring a file lock instruction;

the locking state modifying unit is used for modifying the locking state of the corresponding file in the real-time library according to the file locking instruction; the locked state characterizes that the file only allows editing operations by a single user.

The above description of the apparatus embodiments, similar to the above description of the method embodiments, has similar beneficial effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus of the present application, reference is made to the description of the embodiments of the method of the present application for understanding.

It should be noted that, in the embodiment of the present application, if the cloud programming file management method is implemented in the form of a software functional module and is sold or used as an independent product, the cloud programming file management method may also be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or portions thereof contributing to the prior art may be embodied in the form of a software product stored in a storage medium, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read Only Memory (ROM), a magnetic disk, or an optical disk. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

Correspondingly, the embodiment of the present application provides a cloud programming file management device (e.g., a computer device), which includes a memory and a processor, where the memory stores a computer program that can be run on the processor, and the processor executes the computer program to implement the steps in the cloud programming file management method provided in the above embodiment.

Correspondingly, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, where the computer program is executed by a processor to implement the steps in the cloud programming file management method provided in the foregoing embodiment.

Here, it should be noted that: the above description of the storage medium and device embodiments is similar to the description of the method embodiments above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the storage medium and apparatus of the present application, reference is made to the description of the embodiments of the method of the present application for understanding.

Fig. 5 is a schematic diagram of a hardware entity of a computer device in an embodiment of the present application, and as shown in fig. 5, the hardware entity of the computer device 500 includes: a processor 501, a communication interface 502 and a memory 503, wherein

The processor 501 generally controls the overall operation of the computer device 500.

The communication interface 502 may enable the computer device 500 to communicate with other devices over a network.

The Memory 503 is configured to store instructions and applications executable by the processor 501, and may also buffer data to be processed or already processed by the processor 501 and modules in the computer device 500, and may be implemented by a FLASH Memory (FLASH) or a Random Access Memory (RAM).

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described device embodiments are merely illustrative, for example, the division of the unit is only a logical functional division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units; can be located in one place or distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

Those of ordinary skill in the art will understand that: all or part of the steps for realizing the method embodiments can be completed by hardware related to program instructions, the program can be stored in a computer readable storage medium, and the program executes the steps comprising the method embodiments when executed; and the aforementioned storage medium includes: various media that can store program codes, such as a removable Memory device, a Read Only Memory (ROM), a magnetic disk, or an optical disk.

Alternatively, the integrated units described above in the present application may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as independent products. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied in the form of a software product, where the computer software product is stored in a storage medium, and includes several instructions to enable a cloud programming file management method device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a magnetic or optical disk, or other various media that can store program code.

The above description is only for the embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A cloud programming file management method is characterized by comprising the following steps:

determining a version identification of the project to be checked out according to the project editing instruction;

storing the files of the currently edited project into a historical library corresponding to the real-time library,

wherein the storing the file of the currently edited project into the history library corresponding to the real-time library includes: if the project edited at present is filed for the first time, a historical library corresponding to the real-time library is newly built, the file of the project edited at present is stored in the newly built historical library, and a historical version filed for the first time of the project edited at present is formed;

if the project edited at present is not filed for the first time, storing the file of the project edited at present into a historical library corresponding to the real-time library to form a latest filed historical version of the project edited at present;

in the historical library, all the historical versions of the currently edited project are sequentially stored according to the filing sequence to form a linear version tree.

2. The method of claim 1, wherein storing the file of the currently edited project into a history library corresponding to the live library comprises:

and classifying the files of the currently edited project according to the file types and the historical version information of the files, and respectively storing the classified files into different areas of a historical library corresponding to the real-time library.

3. The method of claim 2, wherein the file types include entity files and directory files, and wherein: the entity file is a file containing entity content data, and the directory file is a file containing storage location data of the entity file.

4. The method according to claim 3, wherein the classifying the files of the currently edited project according to the file types of the files, and respectively storing the classified files in different areas of a history library corresponding to the real-time library comprises:

dividing the files of the project edited currently into a first entity file and a first directory file according to the file types of the files;

storing the first entity file in an entity data area of the historian;

storing the first directory file in a directory information area of the historian.

5. The method of claim 4, further comprising:

creating an information recording file in an information recording area of the historical library;

recording the name of the first entity file, the storage position data of the first entity file and the archived version identification in the information recording file;

and storing the information recording file in an information recording area of the historical library.

6. The method of claim 4, wherein storing the first entity file in an entity data area of the historian comprises:

acquiring a second entity file; the second entity file is an entity file corresponding to the latest archived historical version of the project;

comparing the first entity file with the second entity file to obtain a third entity file; the third entity file comprises an entity file updated by the first entity file compared with the second entity file and a newly added entity file;

storing the third entity file in an entity data area of the historian.

7. The method according to claim 5, wherein the recording the name of the first entity file, the storage location data of the first entity file, and the archived version identification in the information recording file comprises:

acquiring a fourth entity file; the fourth entity file is an entity file corresponding to the latest archived historical version of the project;

comparing the first entity file with the fourth entity file to obtain a fifth entity file, wherein the fifth entity file comprises an entity file updated by the first entity file compared with the fourth entity file, a newly added entity file and a deleted entity file;

and recording the name of the fifth volume file, the storage location data of the fifth volume file, and the archived version id in the information recording file.

8. The method according to any one of claims 1 to 7, wherein the copying the file of the project to be checked out to a newly created real-time library according to the version identification of the project to be checked out comprises: searching files belonging to the project to be checked out according to the version identification of the project to be checked out;

classifying the files of the project to be signed out according to the file types of the files;

and respectively copying the classified files to different areas of the newly-built real-time library.

9. The method according to claim 8, wherein the classifying the files of the project to be checked out according to the file types of the files, and the copying the classified files into different areas of the newly-created live library respectively comprises:

classifying the files of the project to be signed out according to the file types of the files to obtain a fifth volume file and a fifth directory file of the project to be signed out;

copying the fifth volume file into an entity data area of the newly-built real-time library;

and copying the fifth directory file into a directory information area of the newly-built real-time library.

10. The method according to any one of claims 1 to 7, wherein after copying the file of the project to be checked out to a newly-created real-time library according to the version identifier of the project to be checked out, the method further comprises:

acquiring a file locking instruction;

according to the file locking instruction, modifying the locking state of the corresponding file in the real-time library; the locked state characterizes that the file only allows editing operations by a single user.

11. A cloud-programmed-file management apparatus, comprising:

the storage module is used for storing the files of the currently edited project into a historical library corresponding to the real-time library; the storage module is specifically configured to, if the currently edited project is first archived, newly build a history library corresponding to the real-time library, store the file of the currently edited project into the newly built history library, and form a history version of the first archived project of the currently edited project; if the project edited at present is not filed for the first time, storing the file of the project edited at present into a historical library corresponding to the real-time library to form a latest filed historical version of the project edited at present; in the historical library, all the historical versions of the currently edited project are sequentially stored according to the filing sequence to form a linear version tree.

12. A cloud programming file management apparatus, characterized in that the apparatus comprises: a memory storing a computer program operable on a processor, the processor implementing the cloud programming file management method provided in any of claims 1 to 10 when executing the computer program.

13. A computer-readable storage medium having stored therein computer-executable instructions configured to perform the cloud programming file management method provided in any one of claims 1 to 10.