CN117270943A - Cloud application file version management system and method based on metadata - Google Patents

Cloud application file version management system and method based on metadata Download PDF

Info

Publication number
CN117270943A
CN117270943A CN202311192344.2A CN202311192344A CN117270943A CN 117270943 A CN117270943 A CN 117270943A CN 202311192344 A CN202311192344 A CN 202311192344A CN 117270943 A CN117270943 A CN 117270943A
Authority
CN
China
Prior art keywords
version
instruction
metadata
application file
requesting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202311192344.2A
Other languages
Chinese (zh)
Other versions
CN117270943B (en
Inventor
龚敏彦
吕俊
刘威
禄学恩
吴嘉俊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Zixel Technology Co ltd
Original Assignee
Shanghai Zixel Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Zixel Technology Co ltd filed Critical Shanghai Zixel Technology Co ltd
Priority to CN202311192344.2A priority Critical patent/CN117270943B/en
Publication of CN117270943A publication Critical patent/CN117270943A/en
Application granted granted Critical
Publication of CN117270943B publication Critical patent/CN117270943B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G06F16/122—File system administration, e.g. details of archiving or snapshots using management policies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The invention provides a cloud application file version management system and a cloud application file version management method based on metadata, wherein the cloud application file version management system based on the metadata comprises the following steps: the system comprises a webpage front end, a cloud virtual machine, an API intermediate interface layer, a version management system server and a cloud file storage server. According to the technical scheme, version management of the file can be efficiently realized, a branching function is provided, and a multi-person collaboration scene is supported; meanwhile, the method can carry out authority record and file version tracing of the user based on the metadata, realizes integrated management of the file, effectively solves the problem of redundancy of stored data, and overcomes the limitation of PDM and PLM technical schemes in the traditional local management and industrial fields; compared with SVN and Git technical schemes, the method can support and manage complex non-text application model files in the industrial field, and meet the requirements of modifying and integrating large project files.

Description

Cloud application file version management system and method based on metadata
Technical Field
The invention relates to the technical field of cloud file version management, in particular to a cloud application file version management system and method based on metadata.
Background
Currently, version management and multi-person collaboration for data files in the industry has been a widely existing need. The traditional file management mode based on local storage has a plurality of defects: copying a file for each version, the problems of data redundancy and storage inefficiency cannot be avoided; manual operation is needed for version management, and the process is tedious and easy to make mistakes; aiming at a multi-person cooperation scene, the current mode can be realized only through file transmission, and the requirements of efficient and rapid combination of multi-party modification cannot be met.
In the prior art, although Product Data Management (PDM) can widely support the use scenario of industrial software, the version management process is relatively complicated, and requires an administrator to maintain, so that the management cost is high. In addition, the PDM technical scheme has limited project management capability, is not suitable for diversified project requirements, and has limitation in parallel engineering support because document management is set through locking authority, and does not support branch management. While the product life cycle management technology (PLM) based on the PDM can realize large-scale simultaneous collaboration of multiple persons, the purchase, use and learning costs are high, and the support on project management is still to be promoted. Meanwhile, PLM also has document locking problems in terms of parallel engineering support, and does not support branch management.
In the version management system, the SVN is mainly applicable to code management scenes as a centralized version management system, and has limited application in other fields. Meanwhile, the SVN only provides a single centralized management server, and all the cooperative users need to be uniformly connected to the server to acquire/submit files. In contrast, git (open source version control system) is widely applied in the software field, has the characteristic of distributed project data management, and supports efficient parallel collaboration and branch management. However, git is more suitable for text and code management scenarios, and there are some limitations in handling engineering file formats such as binary files. At the same time, technicians need to deal with higher learning curves, which is not easy for industrial designers who are not software technicians to handle.
Therefore, in this technical background, there is an urgent need to develop an innovative file version management system to overcome many limitations of the conventional method and provide an efficient, intelligent, low-cost solution that can be applied in a wide industrial field.
Disclosure of Invention
In order to overcome the technical drawbacks, an object of the present invention is to provide a cloud application file version management system based on metadata, which includes: the system comprises a webpage front end, a cloud virtual machine, an API intermediate interface layer, a version management system server and a cloud file storage server; and information interaction is performed among the front end of the webpage, the cloud virtual machine, the API intermediate interface layer, the version management system server and the cloud file storage server so as to realize one or more functions of creating an application file, editing the application file, fixing a version, calling a historical version, creating branches, deleting the version and merging the version.
Further, the front end of the webpage provides interfaces and interaction components for one or more users, and information interaction is carried out between the interfaces and interaction components and the cloud virtual machine and the API intermediate interface layer respectively: the method comprises the steps of sending an instruction for requesting to build a new application file, an instruction for requesting to edit the application file, an instruction for requesting to fix an application file version, sending metadata, an instruction for requesting to call a history version, an instruction for requesting to delete a cache and call a current latest version file to the cloud virtual machine, and analyzing and displaying differences of different versions by calling a version comparison module of the front end of a webpage; the cloud virtual machine is also used for receiving and displaying the returned information, updated interfaces and merged versions of the cloud virtual machine; the method is also used for sending a request for establishing a data warehouse instruction, a request for executing a fixed application file version instruction, a request for calling a history version instruction, a request for creating a branch instruction, a request for deleting a version instruction and a request for merging a version instruction to an API intermediate interface layer; and the system is also used for receiving the data warehouse ID, the fixed version success information, the metadata, the deletion success and the version information forwarded by the API intermediate interface layer.
Further, the cloud virtual machine is used for receiving an instruction for requesting new application files, an instruction for requesting editing application files, an instruction for requesting fixed application file version, metadata, an instruction for requesting call history version, an instruction for requesting to delete cache and an instruction for calling current latest version files, which are sent by the front end of a webpage; the method is also used for sending return information, updated interfaces and merged versions to the front end of the webpage; the method is also used for sending an instruction for requesting an obs storage address, an instruction for requesting to store metadata, an instruction for requesting an obs cache address, an instruction for requesting to update metadata, an instruction for requesting to clear cache metadata and an obs storage address instruction for requesting to merge data in a version to an API intermediate interface layer; the system is also used for receiving the obs storage address, the obs cache address, the information of successfully clearing the cache metadata and the obs storage address of the data in the merged version returned by the API intermediate interface layer; the method is also used for sending an instruction for requesting to store the application file, an instruction for requesting to call the corresponding application file in the obs storage address, a request for requesting to call the father version application file in the obs storage address and an instruction for requesting to merge version file data to the cloud file storage server; and the cloud file storage server is also used for receiving information that the application files sent by the cloud file storage server are successfully stored, corresponding application files in the obs storage address, father version application files in the obs storage address and merged version file data.
Further, the cloud file storage server is configured to receive an instruction for requesting to store an application file, an instruction for requesting to call a corresponding application file in an obs storage address, a request for requesting to call a parent version application file in the obs storage address, an instruction for requesting to merge version file data, and an application file, which are sent by the cloud virtual machine; the method is also used for sending information of successful storage of the application files, corresponding application files in the obs storage address, father version application files in the obs storage address and merged version file data to the cloud virtual machine; and the method is also used for receiving an instruction which is sent by the API intermediate interface layer and is used for requesting to delete the application file, and returning information of successfully deleting the application file to the API intermediate interface layer.
Further, the API intermediate interface layer is used for receiving a request for establishing a data warehouse instruction, a request for executing a version instruction of a fixed application file, a request for calling a historical version instruction, a request for creating a branch instruction, a request for deleting a version instruction and a request for merging a version instruction which are sent by the front end of a webpage; the method is also used for forwarding the data warehouse ID, the fixed version success information, the metadata, the deletion success and the version information to the front end of the webpage; the method is also used for receiving an instruction for requesting an obs storage address, an instruction for requesting to store metadata, an instruction for requesting an obs cache address, an instruction for requesting to update metadata, an instruction for requesting to clear cache metadata and an obs storage address instruction for requesting to merge data in a version, which are sent by the cloud virtual machine; the method is also used for returning an obs storage address, an obs cache address, information of successfully clearing cache metadata and an obs storage address of data in a merged version to the cloud virtual machine; the method is also used for forwarding an instruction for requesting to establish a storage application file data warehouse to a version management system server, forwarding application file metadata generated by the instruction and an instruction for requesting to store the application file metadata, forwarding the generated updated application file metadata and an instruction for requesting to store the updated application file metadata, forwarding an instruction for requesting to execute a fixed version, forwarding an instruction for clearing cache metadata, analyzing a request call history version instruction and generating and sending a request call history version metadata, forwarding an instruction for requesting to create a branch, forwarding an instruction for requesting to delete a version, sending an instruction for requesting to pull all metadata of versions to be combined and forwarding an instruction for requesting to combine versions; the system is also used for receiving the data warehouse ID of the storage application file returned by the version management system server, the information of a successful fixed version, the information of successful clearing cache metadata, historical version metadata, new branch metadata, the information of successful deleting version, all the metadata of versions to be combined and the metadata of the version after combination; and the cloud file storage server is also used for sending an instruction for requesting to delete the application file to the cloud file storage server and receiving the information of successfully deleting the application file returned by the cloud file storage server.
Further, the version management system server is configured to receive an instruction for requesting to establish a storage application file data repository, an instruction for generating application file metadata and requesting to store application file metadata, an instruction for generating updated application file metadata and requesting to store updated application file metadata, an instruction for requesting to execute a fixed version, an instruction for clearing cache metadata, an instruction for requesting to call history version metadata, an instruction for requesting to create a branch, an instruction for requesting to delete a version, an instruction for requesting to pull all metadata of versions to be combined, and an instruction for requesting to combine versions, which are forwarded by the API intermediate interface layer; and the method is also used for returning the storage application file data warehouse ID, the information of a successful fixed version, the information of successful clearing cache metadata, historical version metadata, new branch metadata, the information of successful deleting version, all metadata of versions to be combined and metadata of the combined version to the API intermediate interface layer.
Further, all interaction information and all metadata among the webpage front end, the cloud virtual machine, the API intermediate interface layer, the version management system server and the cloud file storage server are in json or Protobuf data format.
Further, the application file is a text application file and/or a non-text application file in the industrial field; each application file includes one or more documents that can be pinned to a separate new version when one or more changes in modifying document content, adding new documents, deleting documents occur within the application file. The application file is changed, and is not necessarily fixed to be a new version every time, but the user can choose to fix the application file together after a plurality of changes to be a new version, or choose not to fix the application file to be a new version.
The second aspect of the present application provides a method for cloud application file version management by adopting the metadata-based cloud application file version management system, which includes steps S1 to S4:
step S1: newly-built application file, which includes step S11-step S18:
step 11, one or more users log in to the front end of the webpage at the same time, and send out an instruction for requesting to newly build an application file through interface interaction;
step 12, the front end of the webpage receives instruction information of the newly built application file, sends a request for establishing a data warehouse of the stored application file to an API intermediate interface layer, and forwards the request to a version management server through the API intermediate interface layer;
Step 13, the version management server returns the available data warehouse ID on the current server aiming at the request for establishing and storing the application file data warehouse forwarded by the intermediate interface layer, and the data warehouse ID forwards the web page front end where the user is located back through the API intermediate interface layer;
step 14, after the front end of the webpage acquires the data warehouse ID, sending an instruction for requesting to start the application to the cloud virtual machine;
step 15, after the cloud virtual machine successfully starts the application, sending an instruction for requesting an OBS (object storage service, object Storage Service, OBS) storage address to an API intermediate interface layer; the API intermediate interface layer generates an obs storage key corresponding to the application file, and returns an available obs storage address to the cloud virtual machine;
step 16, automatically storing the application file or after receiving a storage instruction sent by a user by manually clicking a storage button at the front end of a webpage, sending an instruction for requesting to store the application file and the current application file to a cloud file storage server by the cloud virtual machine, and returning successful storage information to the cloud virtual machine by the cloud file storage server;
step 17, the cloud virtual machine returns information to the front end of the webpage, wherein the information comprises a successful storage message and an obs storage address;
step 18, the cloud virtual machine sends an instruction for requesting to store metadata to an API intermediate interface layer, and the API intermediate interface layer generates metadata corresponding to the current application file based on the data warehouse ID and then forwards and stores the metadata to a version management server;
Step S2: editing an application file comprising steps 21-25:
step 21, after requesting to start an application file at the cloud virtual machine and performing editing operation through the front end of the webpage, a user sends an editing and modifying instruction to the cloud virtual machine, and after executing the editing and modifying instruction at the cloud virtual machine, the user generates a modified cache application file;
step 22, the cloud virtual machine sends an instruction for requesting an obs cache address to an API intermediate interface layer; the API intermediate interface layer returns the currently available cache address to the cloud virtual machine;
step 23, after the cloud virtual machine successfully receives the cache address, sending an instruction for requesting to store the application file to a cloud file storage server, and returning storage success information to the cloud virtual machine by the cloud file storage server, wherein only a difference part between a record and a previous cache file or a historical version application file is stored when the cloud file storage server stores the storage success information;
step 24, the cloud virtual machine returns information to the front end of the webpage, wherein the information comprises a successful storage message and an obs storage address;
step 25, the cloud virtual machine sends an instruction for requesting to update metadata to an API intermediate interface layer, the API intermediate interface layer generates metadata corresponding to the edited and modified application file based on the data warehouse ID, and then forwards and saves the updated metadata to a version management server to replace historical metadata;
Step S3: a fixed version comprising steps 31-38:
step 31, a user sends an instruction for requesting to fix the version of the current application file through the front end of the webpage, and the edited and modified application file is temporarily cached at the cloud virtual machine;
step 32, after receiving the request instruction of the fixed version, the cloud virtual machine sends an instruction for requesting the obs storage address to an API intermediate interface layer, and the API intermediate interface layer returns the corresponding obs storage address to the cloud virtual machine;
step 33, after receiving the obs storage address, the cloud virtual machine stores the currently cached application file to the corresponding storage address of the cloud file storage server, and after successful storage, the cloud file storage server sends storage success information to the cloud virtual machine;
step 34, after the cloud virtual machine receives the information of successful storage, sending an instruction for clearing the cache metadata to an API intermediate interface layer, and sending an instruction for executing the clearing of the cache data to a version management server by the API intermediate interface layer for execution;
and 35, after the version management server successfully clears the cache data, returning cache clearing success information to an API intermediate interface layer, and forwarding the cache clearing success information to the cloud virtual machine by the API intermediate interface layer.
Step 36, after the cloud virtual machine receives the cache clearing success information, packaging and returning the storage success information and the obs storage address to the front end of the webpage;
step 37, after receiving the returned storage information, the front end of the web page requests to execute the instruction of the fixed version to the API intermediate interface layer, and forwards the instruction to the version management server through the intermediate layer to store the metadata of the application file under the current version;
step 38, the version management server returns the success information of the fixed version, forwards the success information back to the front end of the webpage through the API intermediate interface layer, and prompts to inform the user;
step S4: managing application file versions, including one or more of steps S41 to S44:
step S41: a call history version, which includes step S411 to step S416:
step S411, the user sends an instruction for requesting to call a certain historical version of the application file to an API intermediate interface layer through the front end of the webpage, after the API intermediate interface layer analyzes the request instruction, the application file ID is obtained after searching, a corresponding request is sent to a version management server, and metadata corresponding to the historical version is requested to be called;
step S412, the version management server returns the metadata corresponding to the history version to the API intermediate interface layer, and the intermediate interface layer forwards the metadata to the front end of the webpage;
Step S413, the front end of the webpage sends the metadata to the cloud virtual machine;
step S414, after the cloud virtual machine receives the metadata, according to the ID of the application file, sending an instruction for requesting the corresponding obs storage address of the application file to an API intermediate interface layer, and returning the obs storage address to the cloud virtual machine by the intermediate interface layer;
step S415, after receiving the obs storage address, the cloud virtual machine sends a request for calling an application file in the storage address to a cloud file storage server, and the cloud file storage server downloads a corresponding application file and transmits the corresponding application file to the cloud virtual machine;
step S416, the cloud virtual machine opens the corresponding application file, and after the interface is updated, the corresponding application file is transmitted back to the front end of the webpage and displayed to the user;
step S42: creating a branch comprising step S421-step S426:
step S421, the user sends an instruction for requesting to create branches to an API intermediate interface layer through the front end of the webpage, after the API intermediate interface layer analyzes the request instruction, the application file ID and father version ID information are obtained after searching, a new branch ID is generated, a corresponding request is sent to a version management server, and after the version management server checks the editing authority of the user, metadata corresponding to the new branches are generated;
step S422, the version management server returns the metadata of the new branch to an API intermediate interface layer, and the intermediate interface layer forwards the metadata to the front end of the webpage;
Step S423, the user sends an instruction for requesting to call the parent version application file based on the new branch to the cloud virtual machine through the front end of the webpage, wherein the instruction contains the parent version application file information based on the branch to be newly created;
step S424, the cloud virtual machine sends an instruction for requesting the obs storage address to an API intermediate interface layer according to the application file of the history version, and the API intermediate interface layer returns the corresponding obs storage address to the cloud virtual machine;
step S425, after receiving the obs storage address, the cloud virtual machine sends a request for calling the application file of the father version in the storage address to a cloud file storage server, and the cloud file storage server downloads the corresponding application file and transmits the application file to the cloud virtual machine;
step S426, the cloud virtual machine opens the application file corresponding to the father version, and after the interface is updated, the application file is transmitted back to the front end of the webpage and displayed to the user, and the user is allowed to enter an editing state;
step S43: delete version, it includes step S431-step S438:
step S431, the user sends a command for requesting to delete the version to the API middle interface layer through the front end of the webpage, wherein the request command comprises an application file name and a version name to be deleted;
step S432, after receiving the deletion request instruction, the version management server checks the deletion authority of the user, deletes the metadata of the version to be deleted at the server side, and returns the deletion success information to the API intermediate interface layer;
Step S433, the API intermediate interface layer searches the corresponding obs storage address according to the version ID to be deleted and sends an instruction for requesting to delete the application file to the cloud file storage server;
in step S434, after the cloud file storage server successfully deletes the history version, the cloud file storage server returns the deletion success information to the API intermediate interface layer, and at the same time, the API intermediate interface layer parses the latest version information, and sends the latest version metadata and the deleted version information to the front end of the web page, where the latest version is the parent version of the deleted history version.
Step S435, the front end of the webpage sends an instruction for requesting to clear the deleted version cache data to the cloud virtual machine according to the received version information, and simultaneously, the front end of the webpage sends an instruction for calling the current latest version and the corresponding metadata thereof to the cloud virtual machine;
step S436, after receiving the metadata of the current latest version, the cloud virtual machine sends an instruction for requesting the obs storage address to an API intermediate interface layer according to the application file ID, and the API intermediate interface layer returns the obs storage address to the cloud virtual machine;
step S437, after the cloud virtual machine receives the obs storage address, a request for calling the application file in the storage address is sent to the cloud file storage server, the cloud file storage server downloads the corresponding application file and transmits the corresponding application file to the cloud virtual machine;
Step S438, the cloud virtual machine opens the application file of the current latest version, and the interface is updated and then transmitted back to the front end of the webpage to be displayed to the user;
step S44: a merged version comprising step S441-step S449:
step S441, the user sends an instruction for requesting to merge versions to an API intermediate interface layer at the front end of the webpage, wherein the instruction comprises name information of the versions to be merged, and after the API intermediate interface layer analyzes the instruction, the user sends a request for pulling metadata of all the versions to be merged to a version management server;
step S442, the version management server returns the metadata of all versions to be combined to the API intermediate interface layer, and forwards the metadata back to the front end of the webpage through the API intermediate interface layer;
step S443, the front end of the webpage is provided with a version analysis module, conflict parts among different versions are analyzed according to metadata of the versions to be merged, comparison results of the different versions are displayed at an interface, and the user is waited to select the version content to be reserved and merged in the conflict parts;
step S444, after the user finishes screening the merging conflict part through the front end of the webpage, the front end of the webpage sends an instruction for requesting to merge the version to an API intermediate interface layer, and the API intermediate interface layer forwards the merging instruction to a version management server to generate metadata corresponding to the merged version;
Step S445, the version management server returns the metadata of the merged version to the API intermediate interface layer, and returns to the front end of the web page via the API intermediate interface layer;
step S446, the front end of the webpage sends the merged version metadata to the cloud virtual machine;
step S447, the cloud virtual machine sends an obs storage address of the data in the request merge version to the API intermediate interface layer, and the API intermediate interface layer returns an address to the cloud virtual machine;
step S448, the cloud virtual machine sends the version file data after request combination to a cloud file storage server according to the returned obs storage address, and the cloud file storage server downloads and transmits the corresponding file data to the cloud virtual machine;
step 449, the cloud virtual machine finishes loading, displays the state of the combined version file, updates the interface, transmits the updated interface back to the front end of the webpage, and displays the updated interface to the user.
Further, in step 18, the information contained in the metadata of the application file to be stored includes: metadata repository ID, application file name, application file ID, primary branch name, primary branch ID, obs storage key, creation user ID, creation time; in step 25, the metadata requested to be updated includes updated information: applying the obs cache key of all documents in the file, modifying the user ID and the latest modification time; in step 37, the executing the fixed version instruction includes: the method comprises the steps of storing keys of the obs of all documents in an application file of a current version to be fixed, branch names, branch IDs, version names, version IDs, father version names, father version IDs, version remark information, version creation user IDs and version creation time of the application file; in step 412, the metadata returned in the version management server includes the following information: the method comprises the steps of an application file name, an application file ID, an obs storage key of all documents in a version application file to be called, a branch name, a branch ID, a version name, a version ID, a father version name, a father version ID, version remark information, a version creation user and a version creation time of the application file; in step S422, the new branch metadata returned by the version management system server includes: application file name, application file ID, newly created branch name, newly created branch ID, obs storage key of newly created branch, branch creation user, and branch creation time; in step S442, metadata returned by the version management system server includes: application file name, application file ID and all version information to be combined; the all version information to be combined comprises: the keys are stored corresponding to the version name, version ID, branch name, and the obs of all documents in the version for each version.
After the technical scheme is adopted, compared with the prior art, the method has the following beneficial effects:
the invention provides a cloud application file version management system and method based on metadata, which adopt the technical scheme logic of Git, can efficiently realize the version management of files and provide branching functions, and support a multi-user collaboration scene. Meanwhile, the method can carry out authority record and file version tracing of the user based on the metadata, realizes integrated management of the file, effectively solves the problem of redundancy of stored data, and overcomes the limitation of PDM and PLM technical schemes in the traditional local management and industrial fields. Compared with SVN and Git technical schemes, the method can support and manage complex non-text application model files in the industrial field, and meet the requirements of modifying and integrating large project files.
Drawings
Fig. 1 is a schematic structural diagram of a cloud application file version management system based on metadata in the application;
fig. 2 is an information interaction diagram when the cloud application file version management system based on metadata is adopted to create an application file;
fig. 3 is an information interaction diagram when the cloud application file version management system based on metadata is adopted to edit an application file;
Fig. 4 is an information interaction diagram when the cloud application file version management system based on metadata is adopted to perform a fixed version;
fig. 5 is a schematic diagram of a front-end interface change when the cloud application file version management system based on metadata is used for performing a fixed version;
fig. 6 is an information interaction diagram when the cloud application file version management system based on metadata is adopted to call a history version;
fig. 7 is an information interaction diagram when creating branches by adopting the cloud application file version management system based on metadata;
fig. 8 is a schematic diagram of a front end interface change when creating a branch by using the cloud application file version management system based on metadata;
fig. 9 is an information interaction diagram when the cloud application file version management system based on metadata is adopted to delete a version;
fig. 10 is an information interaction diagram when the cloud application file version management system based on metadata is adopted to perform merging versions;
fig. 11 is a schematic diagram of a front-end interface change when the metadata-based cloud application file version management system is used for merging versions.
Detailed Description
Advantages of the invention are further illustrated in the following description, taken in conjunction with the accompanying drawings and detailed description. It is to be understood by persons skilled in the art that the following detailed description is illustrative and not restrictive, and that this invention is not limited to the details given herein.
As shown in fig. 1, the present embodiment provides a cloud application file version management system based on metadata, which includes: the system comprises a webpage front end, a cloud virtual machine, an API intermediate interface layer, a version management system server and a cloud file storage server. And information interaction is performed among the front end of the webpage, the cloud virtual machine, the API intermediate interface layer, the version management system server and the cloud file storage server so as to realize one or more functions of creating an application file, editing the application file, fixing a version, calling a historical version, creating branches, deleting the version and merging the version.
All interaction information and all metadata among the webpage front end, the cloud virtual machine, the API intermediate interface layer, the version management system server and the cloud file storage server are in json or Protobuf data format.
The concept of an application file in this application is distinguished from a traditional single file, which herein refers to an engineering project that an application can edit, which may contain a single document or multiple associated documents. The application files in the application are text class application files and/or non-text class application files in the industrial field. Each application file includes one or more documents that can be fixed as a separate new version when one or more changes occur within the application file that modify document content, add new documents, delete documents. Examples are as follows:
(1) An application file (only comprising a single document 1) can be fixed into a version 1, and the metadata of the version 1 has the ob storage address 1 of the document 1;
(2) An application file (comprising a modified document 1) can be fixed to be a version 2, and the metadata of the version 2 needs to be updated with the obs storage address 2 of the modified document 1;
(3) The application file (comprising the modified document 1+the internal newly added document 2) can be fixed into a version 3, and at the moment, the metadata of the version 3 needs to comprise the obs storage address 2 of the modified document 1 and the obs storage address 3 of the newly added document 2;
(4) The application file (containing document 1+ modified document 2 consistent with version 3) may be fixed to version 4, where the metadata of version 4 needs to contain the obs storage address 2 of modified document 1 and the obs storage address 4 of modified document 2.
The application file may contain a single document or multiple documents. An associated document refers to documents that may have dependencies, such as an assembly document referencing multiple part documents. But the assembly document itself and its associated part document are all internal to an application file.
The webpage front end provides interfaces and interaction components for one or more users, and performs information interaction with the cloud virtual machine and the API intermediate interface layer respectively: the method comprises the steps of sending an instruction for requesting to build a new application file, an instruction for requesting to edit the application file, an instruction for requesting to fix an application file version, sending metadata, an instruction for requesting to call a history version, an instruction for requesting to delete a cache and call a current latest version file to the cloud virtual machine, and analyzing and displaying differences of different versions by calling a version comparison module of the front end of a webpage; the cloud virtual machine is also used for receiving and displaying the returned information, updated interfaces and merged versions of the cloud virtual machine; the method is also used for sending a request for establishing a data warehouse instruction, a request for executing a fixed application file version instruction, a request for calling a history version instruction, a request for creating a branch instruction, a request for deleting a version instruction and a request for merging a version instruction to an API intermediate interface layer; and the system is also used for receiving the data warehouse ID, the fixed version success information, the metadata, the deletion success and the version information forwarded by the API intermediate interface layer.
The cloud virtual machine is used for receiving an application file creation request instruction, an application file editing request instruction, an application file version fixing request instruction, metadata, a history version calling request instruction, a cache deleting request and a current latest version file calling request instruction sent by the front end of the webpage; the method is also used for sending return information, updated interfaces and merged versions to the front end of the webpage; the method is also used for sending an instruction for requesting an obs storage address, an instruction for requesting to store metadata, an instruction for requesting an obs cache address, an instruction for requesting to update metadata, an instruction for requesting to clear cache metadata and an obs storage address instruction for requesting to merge data in a version to an API intermediate interface layer; the system is also used for receiving the obs storage address, the obs cache address, the information of successfully clearing the cache metadata and the obs storage address of the data in the merged version returned by the API intermediate interface layer; the method is also used for sending an instruction for requesting to store the application file, an instruction for requesting to call the corresponding application file in the obs storage address, a request for requesting to call the father version application file in the obs storage address and an instruction for requesting to merge version file data to the cloud file storage server; and the cloud file storage server is also used for receiving information that the application files sent by the cloud file storage server are successfully stored, corresponding application files in the obs storage address, father version application files in the obs storage address and merged version file data.
The API intermediate interface layer is used for receiving a request for establishing a data warehouse instruction, a request for executing a version instruction of a fixed application file, a request for calling a historical version instruction, a request for creating a branch instruction, a request for deleting a version instruction and a request for merging a version instruction which are sent by the front end of a webpage; the method is also used for forwarding the data warehouse ID, the fixed version success information, the metadata, the deletion success and the version information to the front end of the webpage; the method is also used for receiving an instruction for requesting an obs storage address, an instruction for requesting to store metadata, an instruction for requesting an obs cache address, an instruction for requesting to update metadata, an instruction for requesting to clear cache metadata and an obs storage address instruction for requesting to merge data in a version, which are sent by the cloud virtual machine; the method is also used for returning an obs storage address, an obs cache address, information of successfully clearing cache metadata and an obs storage address of data in a merged version to the cloud virtual machine; the method is also used for forwarding an instruction for requesting to establish a storage application file data warehouse to a version management system server, forwarding application file metadata generated by the instruction and an instruction for requesting to store the application file metadata, forwarding the generated updated application file metadata and an instruction for requesting to store the updated application file metadata, forwarding an instruction for requesting to execute a fixed version, forwarding an instruction for clearing cache metadata, analyzing a request call history version instruction and generating and sending a request call history version metadata, forwarding an instruction for requesting to create a branch, forwarding an instruction for requesting to delete a version, sending an instruction for requesting to pull all metadata of versions to be combined and forwarding an instruction for requesting to combine versions; the system is also used for receiving the data warehouse ID of the storage application file returned by the version management system server, the information of a successful fixed version, the information of successful clearing cache metadata, historical version metadata, new branch metadata, the information of successful deleting version, all the metadata of versions to be combined and the metadata of the version after combination; and the cloud file storage server is also used for sending an instruction for requesting to delete the application file to the cloud file storage server and receiving the information of successfully deleting the application file returned by the cloud file storage server.
The version management system server is used for receiving an instruction for requesting to establish a storage application file data warehouse, the generated application file metadata and an instruction for requesting to store the application file metadata, the generated updated application file metadata and an instruction for requesting to store the updated application file metadata, an instruction for requesting to execute a fixed version, an instruction for clearing cache metadata, an instruction for requesting to call historical version metadata, an instruction for requesting to create a branch, an instruction for requesting to delete a version, an instruction for requesting to pull all metadata of versions to be combined and an instruction for requesting to combine versions, which are forwarded by the API intermediate interface layer; and the method is also used for returning the storage application file data warehouse ID, the information of a successful fixed version, the information of successful clearing cache metadata, historical version metadata, new branch metadata, the information of successful deleting version, all metadata of versions to be combined and metadata of the combined version to the API intermediate interface layer.
The cloud file storage server is used for receiving an instruction which is sent by the cloud virtual machine and is used for requesting to store an application file, an instruction which is used for requesting to call a corresponding application file in the obs storage address, a request which is used for requesting to call a father version application file in the obs storage address, a version file data instruction which is used for requesting to combine, and an application file; the method is also used for sending information of successful storage of the application files, corresponding application files in the obs storage address, father version application files in the obs storage address and merged version file data to the cloud virtual machine; and the method is also used for receiving an instruction which is sent by the API intermediate interface layer and is used for requesting to delete the application file, and returning information of successfully deleting the application file to the API intermediate interface layer.
The method for managing the cloud application file version by adopting the cloud application file version management system based on the metadata comprises the following steps of S1-S4:
step S1: newly created application files, as shown in fig. 2, include step S11-step S18:
step 11, one or more users log in to the front end of the webpage at the same time, and send out an instruction for requesting to newly build an application file through interface interaction;
step 12, the front end of the webpage receives instruction information of the newly built application file, sends a request for establishing a data warehouse of the stored application file to an API intermediate interface layer, and forwards the request to a version management server through the API intermediate interface layer;
step 13, the version management server returns the available data warehouse ID on the current server aiming at the request for establishing and storing the application file data warehouse forwarded by the intermediate interface layer, and the data warehouse ID forwards the web page front end where the user is located back through the API intermediate interface layer;
step 14, after the front end of the webpage acquires the data warehouse ID, sending an instruction for requesting to start the application to the cloud virtual machine;
step 15, after the cloud virtual machine successfully starts the application, sending an instruction for requesting an OBS (object storage service, object Storage Service, OBS) storage address to an API intermediate interface layer; the API intermediate interface layer generates an obs storage key corresponding to the application file, and returns an available obs storage address to the cloud virtual machine; when the cloud virtual machine sends an instruction for requesting the obs storage address to the API intermediate interface layer, the instruction for requesting the obs storage address can contain information of the obs storage key, and the API intermediate interface layer can retrieve the obs storage address corresponding to the application file through the obs storage key in the instruction and return the obs storage address to the cloud virtual machine;
Step 16, automatically storing the application file or after receiving a storage instruction sent by a user by manually clicking a storage button at the front end of a webpage, sending an instruction for requesting to store the application file and the current application file to a cloud file storage server by the cloud virtual machine, and returning successful storage information to the cloud virtual machine by the cloud file storage server;
step 17, the cloud virtual machine returns information to the front end of the webpage, wherein the information comprises a successful storage message and an obs storage address;
step 18, the cloud virtual machine sends an instruction for requesting to store metadata to an API intermediate interface layer, and the API intermediate interface layer generates metadata corresponding to the current application file based on the data warehouse ID and then forwards and stores the metadata to a version management server; in this step, the information included in the metadata of the application file to be stored includes: metadata repository ID, application file name, application file ID, primary branch name, primary branch ID, obs storage key, creation user ID, creation time. Wherein the application file is default to a main branch when created. The method comprises the steps of storing an obs storage key for the obs corresponding to an independent empty file in a current created application file.
In the current link, the user does not execute the fixed version instruction, the metadata of the application file does not correspond to any file version, and the metadata can be understood as cache metadata in the state of newly-built application file, so that the metadata information related to the version or the branch is not included.
The method comprises the steps of creating a request instruction of an application file at the front end of a webpage in step 11, creating a request instruction of a data warehouse at the front end of the webpage in step 12, forwarding the request instruction of the data warehouse by an API intermediate interface layer in step 12, forwarding a warehouse ID returned by a version management server in step 13, forwarding the warehouse ID forwarded by the API intermediate interface layer in step 13, requesting an instruction of starting an application at the front end of the webpage in step 14, requesting an obs storage address by a cloud virtual machine in step 15, returning information of the front end of the webpage by the cloud virtual machine in step 17, requesting a metadata storage instruction by the cloud virtual machine in step 18, and transmitting metadata by the API intermediate interface layer in step 18 by adopting data formats including, but not limited to json, protobuf and the like so as to realize efficient information transmission and reduce network delay. After the metadata is successfully stored in the version management server in step 18, the version management server may not return the storage success information for the case of automatic storage in step 16, so as to save the communication cost. For the case where the user manually requests a save at step 16, the present management server may return a store success message. This information will be returned to the front end of the web page via the API intermediate interface layer, prompting the user.
Step S2: editing an application file, as shown in fig. 3, which includes steps 21-25:
step 21, after requesting to start an application file at the cloud virtual machine and performing editing operation through the front end of the webpage, a user sends an editing and modifying instruction to the cloud virtual machine, and after executing the editing and modifying instruction at the cloud virtual machine, the user generates a modified cache application file;
step 22, the cloud virtual machine sends an instruction for requesting an obs cache address to an API intermediate interface layer; the API intermediate interface layer returns the currently available cache address to the cloud virtual machine; the method comprises the steps that an obs cache address of an application file is not an obs storage address generated for a new application file link;
step 23, after the cloud virtual machine successfully receives the cache address, sending an instruction for requesting to store the application file to the cloud file storage server, and returning storage success information to the cloud virtual machine by the cloud file storage server, wherein only a difference part between the record and the previous cache file or the historical version application file is stored when the cloud file storage server stores the application file, but not the integral storage of the modified application file, so that data redundancy is avoided;
step 24, the cloud virtual machine returns information to the front end of the webpage, wherein the information comprises a successful storage message and an obs storage address;
Step 25, the cloud virtual machine sends an instruction for requesting to update metadata to an API intermediate interface layer, the API intermediate interface layer generates metadata corresponding to the edited and modified application file based on the data warehouse ID, and then forwards and saves the updated metadata to a version management server to replace historical metadata; in this step, the metadata requested to be updated includes updated information: the method comprises the steps of applying the obs cache keys of all documents in the file (the obs cache addresses corresponding to all documents are conveniently requested), modifying the user ID and updating the time.
The editing operation of the user includes, but is not limited to, performing interactive operation and editing through a web page front-end interface, and uploading and downloading the local resource file to the cloud application file.
The request instruction for modifying the application file is edited in step 21, the cloud virtual machine requests the instruction of the obs storage address in step 22, the cloud virtual machine requests the instruction of storing the application file in step 23, the storage success information returned by the cloud file storage server in step 23, the information returned by the cloud virtual machine to the front end of the webpage in step 24, and the instruction and the metadata for requesting the metadata to be updated by the cloud virtual machine in step 25 can adopt data formats including, but not limited to json, protobuf and the like, so that efficient information transmission is realized, and network delay is reduced.
In the current link, because the user does not execute the fixed version instruction, only the historical version information before editing and modifying is maintained in the metadata of the application file, and no new version information is generated to the metadata.
The subsequent editing and modifying operation of the application file by the user and the storage and updating process after the step 21 can be performed asynchronously, that is, the storage processes of the step 22 to the step 25 do not affect the user to continuously edit the application file at the front end of the web page.
The basic idea is similar to the flow after step 14 of the "new application file" link.
Step S3: a fixed version, as shown in fig. 4, comprising steps 31-38:
step 31, a user sends an instruction for requesting to fix the version of the current application file through the front end of the webpage, and the edited and modified application file is temporarily cached at the cloud virtual machine; the fixed version request instruction is initiated by a user and requires the user to input a version name and version remark information through a web page front-end interface. And the request fixed version instruction transmitted to the cloud virtual machine temporarily does not contain version name information and remark information. (it will be understood that the user needs to send a fixed version instruction to the cloud virtual machine to complete a part of preparation work, and then formally execute the fixed version instruction in step 37.)
Step 32, after receiving the request instruction of the fixed version, the cloud virtual machine sends an instruction for requesting the obs storage address to an API intermediate interface layer, and the API intermediate interface layer returns the corresponding obs storage address to the cloud virtual machine; the obs storage address of the application file is generated by creating an application file link;
step 33, after receiving the obs storage address, the cloud virtual machine stores the currently cached application file to the corresponding storage address of the cloud file storage server, and after successful storage, the cloud file storage server sends storage success information to the cloud virtual machine;
step 34, after the cloud virtual machine receives the information of successful storage, sending an instruction for clearing the cache metadata to an API intermediate interface layer, and sending an instruction for executing the clearing of the cache data to a version management server by the API intermediate interface layer for execution;
step 35, after the version management server successfully clears the cache data, returning the information of clearing the cache to an API intermediate interface layer, and forwarding the information of successfully clearing the cache to the cloud virtual machine by the API intermediate interface layer;
step 36, after the cloud virtual machine receives the cache clearing success information, packaging and returning the storage success information and the obs storage address to the front end of the webpage;
Step 37, after receiving the returned storage information, the front end of the web page requests to execute the instruction of the fixed version to the API intermediate interface layer, and forwards the instruction to the version management server through the intermediate layer to store the metadata of the application file under the current version; the request fixed version instruction received by the API intermediate interface layer includes version name and version remark information input by the user in step 1, and the version name and version remark information are stored in metadata of the application file, and in this step, executing the fixed version instruction includes that metadata information to be updated is included: the method comprises the steps of storing keys of the obs of all documents in the application file of the current version to be fixed, and branching names, branching IDs, version names, version IDs, father version names, father version IDs, version remark information, version creation user IDs and version creation time of the application file. The parent version is the last history version based on the current version to be fixed. The data information in the fixed version is added to the version information list in the metadata in a unified way, so that the related information of the last version cannot be covered when the new version is fixed.
Step 38, the version management server returns the success information of the fixed version, and forwards the success information back to the front end of the webpage through the API intermediate interface layer, so as to prompt and inform the user, as shown in fig. 5;
The method comprises the steps of requesting a fixed version instruction by a front end of a webpage in step 31, requesting an obs storage address instruction by a cloud virtual machine in step 32, requesting an application file storage instruction by the cloud virtual machine in step 33, storing success information returned by a cloud file storage server in step 33, requesting a cache data clearing instruction by the cloud virtual machine in step 34, clearing the cache data instruction by an API intermediate interface layer in step 34, clearing the cache data success information returned by a version management server in step 35, forwarding the returned cache clearing success information by the API intermediate interface layer in step 35, storing information returned by the cloud virtual machine in step 36, requesting an execution of the fixed version instruction by the front end of the webpage in step 37, requesting an execution of the fixed version instruction by the API intermediate interface layer in step 37, transmitting the fixed version success information by the version management server in step 38, and forwarding the fixed version success information forwarded by the API intermediate interface layer in step 38 can adopt data formats including, but not limited to json, protobuf and the like, so as to realize efficient information transmission and reduce network delay.
Step S4: managing application file versions, including one or more of steps S41 to S44:
step S41: the call history version, as shown in fig. 6, includes steps S411 to S416:
Step S411, a user sends an instruction for requesting to call a certain historical version of an application file to an API intermediate interface layer through the front end of a webpage, wherein the request instruction comprises an application file name and a historical version name, the API intermediate interface layer obtains an application file ID after analyzing the request instruction, and sends a corresponding request to a version management server to request to call metadata corresponding to the historical version;
step S412, the version management server returns the metadata corresponding to the history version to the API intermediate interface layer, and the intermediate interface layer forwards the metadata to the front end of the webpage; there is no modification to the metadata in this link. In this step, the metadata returned in the version management server includes the following information: the method comprises the steps of an application file name, an application file ID, an obs storage key of all documents in a version application file to be called, a branch name, a branch ID, a version name, a version ID, a father version name, a father version ID, version remark information, a version creation user and a version creation time of the application file;
step S413, the front end of the webpage sends the metadata to the cloud virtual machine; the forwarding of the metadata in step 412 and step 413 by the front end of the web page is convenient for the following user to directly call the metadata without additional request when the user requests to create branches through the front end of the web page, so that the communication cost is saved;
Step S414, after the cloud virtual machine receives the metadata, according to the ID of the application file, sending an instruction for requesting the corresponding obs storage address of the application file to an API intermediate interface layer, and returning the obs storage address to the cloud virtual machine by the intermediate interface layer;
step S415, after receiving the obs storage address, the cloud virtual machine sends a request for calling an application file in the storage address to a cloud file storage server, and the cloud file storage server downloads a corresponding application file and transmits the corresponding application file to the cloud virtual machine;
step S416, the cloud virtual machine opens the corresponding application file, and after the interface is updated, the corresponding application file is transmitted back to the front end of the webpage and displayed to the user; the application text after the historical version is called only supports operations such as checking, view switching, exporting and the like of a user, and editing and modification cannot be carried out on the application text;
the instruction of requesting to call the historical version by the front end of the web page in the step 411, the instruction of requesting the metadata of the historical version by the API intermediate interface layer in the step 411, the instruction of requesting the obs storage address by the cloud virtual machine in the step 414, and the instruction of requesting to call the file by the cloud virtual machine in the step 412 may adopt data formats including json, protobuf and the like, so as to realize efficient information transmission and reduce network delay;
Step S42: a branch is created, as shown in fig. 7, comprising steps S421-S426:
step S421, a user sends an instruction for requesting to create a branch to an API intermediate interface layer through the front end of a webpage, wherein the request instruction comprises an application file name, a new branch name and a father version name based on the new branch, the API intermediate interface layer obtains application file ID and father version ID information after analyzing the request instruction, generates a new branch ID, sends a corresponding request to a version management server, and the version management server generates metadata corresponding to the new branch after checking editing authority of the user;
step S422, the version management server returns the metadata of the new branch to an API intermediate interface layer, and the intermediate interface layer forwards the metadata to the front end of the webpage; in this step, the new branch metadata returned by the version management system server includes: application file name, application file ID, newly created branch name, newly created branch ID, obs storage key of newly created branch, branch creation user, branch creation time, etc.
Step S423, the user sends an instruction for requesting to call the parent version application file based on the new branch to the cloud virtual machine through the front end of the webpage, wherein the instruction contains the parent version application file information based on the branch to be newly created;
Step S424, the cloud virtual machine sends an instruction for requesting the obs storage address to an API intermediate interface layer according to the application file of the history version, and the API intermediate interface layer returns the corresponding obs storage address to the cloud virtual machine;
step S425, after receiving the obs storage address, the cloud virtual machine sends a request for calling the application file of the father version in the storage address to a cloud file storage server, and the cloud file storage server downloads the corresponding application file and transmits the application file to the cloud virtual machine;
step S426, the cloud virtual machine opens the application file corresponding to the father version, the interface is updated and then transmitted back to the front end of the webpage to be displayed to the user, as shown in FIG. 8, and the user is allowed to enter an editing state;
the instruction of creating a branch is requested by the front end of the web page in step 421, the instruction of creating a branch is requested by the API intermediate interface layer in step 421, the new branch metadata is returned by the version management server in step 422, the new branch metadata is returned by the API intermediate interface layer in step 422, the instruction of calling a history version is requested by the front end of the web page in step 423, the instruction of requesting an obs storage address by the cloud virtual machine in step 424, and the instruction of calling a file by the cloud virtual machine in step 425 can be in a data format including, but not limited to, json, protobuf and the like, so that efficient information transmission is realized, and network delay is reduced; step S43: the deleted version, as shown in fig. 9, includes steps S431-S438:
Step S431, the user sends a command for requesting to delete the version to the API middle interface layer through the front end of the webpage, wherein the request command comprises an application file name and a version name to be deleted;
the version to be deleted must be the latest historical version on the branch, and the user cannot skip to delete the non-latest historical version or the historical version with the sub-branch on the branch, which can be understood that one branch B1 has a version of V1-V2-V3, the other branch B2 is a version of V2-V4, V2 is generated based on V1, and V3 and V4 are generated based on V2; here, the user can delete only V3 or V4, but cannot delete V2, and even if the user has deleted the V3 version, only the V1-V2 version remains on branch B1, but since the V4 version is associated with the V2 version, V2 cannot be deleted even if it is the latest history version on branch B1;
step S432, after receiving the deletion request instruction, the version management server checks the deletion authority of the user, deletes the metadata of the version to be deleted at the server side, and returns the deletion success information to the API intermediate interface layer;
step S433, the API intermediate interface layer searches the corresponding obs storage address according to the version ID to be deleted and sends an instruction for requesting to delete the application file to the cloud file storage server;
Step S434, after the cloud file storage server successfully deletes the historical version, returning deletion success information to the API intermediate interface layer, analyzing by the API intermediate interface layer to obtain current latest version information, and sending the current latest version metadata and deleted version information to the front end of the webpage, wherein the current latest version is the father version of the deleted historical version;
step S435, the front end of the webpage sends an instruction for requesting to clear the deleted version cache data to the cloud virtual machine according to the received version information, and simultaneously, the front end of the webpage sends an instruction for calling the current latest version and the corresponding metadata thereof to the cloud virtual machine;
step S436, after receiving the metadata of the current latest version, the cloud virtual machine sends an instruction for requesting the obs storage address to an API intermediate interface layer according to the application file ID, and the API intermediate interface layer returns the obs storage address to the cloud virtual machine;
step S437, after the cloud virtual machine receives the obs storage address, a request for calling the application file in the storage address is sent to the cloud file storage server, the cloud file storage server downloads the corresponding application file and transmits the corresponding application file to the cloud virtual machine;
step S438, the cloud virtual machine opens the application file of the current latest version, and the interface is updated and then transmitted back to the front end of the webpage to be displayed to the user;
The instruction of the version deletion request from the front end of the web page in step 431, the instruction of the version deletion request forwarded by the API intermediate interface layer in step 431, the deletion success information returned by the version management server in step 432, the deletion application file instruction sent by the API intermediate interface layer in step 433, the deletion success information returned by the cloud file memory in step 434, the deletion success information and the version information forwarded by the API intermediate interface layer in step 434, the instruction of the cache deletion request and the call request sent by the front end of the web page in step 435, the instruction of the obs storage address request of the cloud virtual machine in step 436, and the instruction of the file call request of the cloud virtual machine in step 437 can adopt data formats including, but not limited to json, protobuf and the like, so as to realize efficient information transmission and reduce network delay;
step S44: the merged version, as shown in fig. 10, includes steps S441-S449:
step S441, the user sends an instruction for requesting to merge versions to an API intermediate interface layer at the front end of the webpage, wherein the instruction comprises name information of the versions to be merged, wherein the user can select to merge two or more versions, and after the API intermediate interface layer analyzes the instruction, the API intermediate interface layer sends a request for requesting to pull metadata of all the versions to be merged to a version management server; wherein, generally, the versions selected by the user need to come from different branches;
Step S442, the version management server returns the metadata of all versions to be combined to the API intermediate interface layer, and forwards the metadata back to the front end of the webpage through the API intermediate interface layer; in this step, metadata returned by the version management system server includes: application file name, application file ID and all version information to be combined; the all version information to be combined comprises: version name, version ID, branch name, obs storage key of all documents in the version, and the like.
Step S443, the front end of the webpage is provided with a version analysis module which analyzes conflict parts among different versions according to metadata of versions to be combined, and shows comparison results of the different versions at an interface, and waits for a user to select the version content to be reserved and combined in the conflict parts, wherein the version analysis module can be realized by using a programming language including but not limited to C++;
step S444, after the user finishes screening the merging conflict part through the front end of the webpage, the front end of the webpage sends an instruction for requesting to merge the version to an API intermediate interface layer, and the API intermediate interface layer forwards the merging instruction to a version management server to generate metadata corresponding to the merged version;
Step S445, the version management server returns the metadata of the merged version to the API intermediate interface layer, and returns to the front end of the web page via the API intermediate interface layer;
step S446, the front end of the webpage sends the merged version metadata to the cloud virtual machine;
step S447, the cloud virtual machine sends an obs storage address of the data in the request merge version to the API intermediate interface layer, and the API intermediate interface layer returns an address to the cloud virtual machine;
step S448, the cloud virtual machine sends the version file data after request combination to a cloud file storage server according to the returned obs storage address, and the cloud file storage server downloads and transmits the corresponding file data to the cloud virtual machine;
step S449, the cloud virtual machine completes loading, displays the state of the combined version file, updates the interface, transmits the updated version file back to the front end of the web page, and displays the updated version file to the user, as shown in fig. 11;
the instruction of merging the version is requested by the front end of the web page in step 441, the instruction of pulling the version is requested by the API intermediate interface layer in step 441, the metadata information returned by the version management server in step 442, the metadata information forwarded by the API intermediate interface layer in step 442, the instruction of merging the version is requested by the front end of the web page in step 444, the merging instruction is executed and sent by the API intermediate interface layer in step 444, the metadata information returned by the version management server in step 445, the metadata information forwarded by the API intermediate interface layer in step 445, the merged version information sent by the front end of the web page in step 446, the instruction of requesting the obs storage address by the cloud virtual machine in step 447, and the instruction of requesting the merged version data by the cloud virtual machine in step 448 can adopt data formats including, but not limited to json, protobuf and the like, so as to realize efficient information transmission and reduce network delay.
It should be noted that the embodiments of the present invention are preferred and not limited in any way, and any person skilled in the art may make use of the above-disclosed technical content to change or modify the same into equivalent effective embodiments without departing from the technical scope of the present invention, and any modification or equivalent change and modification of the above-described embodiments according to the technical substance of the present invention still falls within the scope of the technical scope of the present invention.

Claims (10)

1. A cloud application file version management system based on metadata, comprising: the system comprises a webpage front end, a cloud virtual machine, an API intermediate interface layer, a version management system server and a cloud file storage server; and information interaction is performed among the front end of the webpage, the cloud virtual machine, the API intermediate interface layer, the version management system server and the cloud file storage server so as to realize one or more functions of creating an application file, editing the application file, fixing a version, calling a historical version, creating branches, deleting the version and merging the version.
2. The metadata-based cloud application file version management system of claim 1, wherein the web page front end provides an interface and an interaction component to one or more users, and performs information interaction with a cloud virtual machine and an API intermediate interface layer, respectively: the method comprises the steps of sending an instruction for requesting to build a new application file, an instruction for requesting to edit the application file, an instruction for requesting to fix an application file version, sending metadata, an instruction for requesting to call a history version, an instruction for requesting to delete a cache and call a current latest version file to the cloud virtual machine, and analyzing and displaying differences of different versions by calling a version comparison module of the front end of a webpage; the cloud virtual machine is also used for receiving and displaying the returned information, updated interfaces and merged versions of the cloud virtual machine; the method is also used for sending a request for establishing a data warehouse instruction, a request for executing a fixed application file version instruction, a request for calling a history version instruction, a request for creating a branch instruction, a request for deleting a version instruction and a request for merging a version instruction to an API intermediate interface layer; and the system is also used for receiving the data warehouse ID, the fixed version success information, the metadata, the deletion success and the version information forwarded by the API intermediate interface layer.
3. The cloud application file version management system based on metadata as claimed in claim 1, wherein the cloud virtual machine is configured to receive an instruction for requesting new application files, an instruction for requesting editing application files, an instruction for requesting fixed application file versions, metadata, an instruction for requesting call history versions, an instruction for requesting deletion of a cache, and an instruction for calling a current latest version file sent by a front end of a web page; the method is also used for sending return information, updated interfaces and merged versions to the front end of the webpage; the method is also used for sending an instruction for requesting an obs storage address, an instruction for requesting to store metadata, an instruction for requesting an obs cache address, an instruction for requesting to update metadata, an instruction for requesting to clear cache metadata and an obs storage address instruction for requesting to merge data in a version to an API intermediate interface layer; the system is also used for receiving the obs storage address, the obs cache address, the information of successfully clearing the cache metadata and the obs storage address of the data in the merged version returned by the API intermediate interface layer; the method is also used for sending an instruction for requesting to store the application file, an instruction for requesting to call the corresponding application file in the obs storage address, a request for requesting to call the father version application file in the obs storage address and an instruction for requesting to merge version file data to the cloud file storage server; and the cloud file storage server is also used for receiving information that the application files sent by the cloud file storage server are successfully stored, corresponding application files in the obs storage address, father version application files in the obs storage address and merged version file data.
4. The cloud application file version management system based on metadata as claimed in claim 1, wherein the cloud file storage server is configured to receive an instruction for requesting to store an application file, an instruction for requesting to call a corresponding application file in an obs storage address, a request for requesting to call a parent version application file in the obs storage address, an instruction for requesting to merge version file data, and an application file sent by the cloud virtual machine; the method is also used for sending information of successful storage of the application files, corresponding application files in the obs storage address, father version application files in the obs storage address and merged version file data to the cloud virtual machine; and the method is also used for receiving an instruction which is sent by the API intermediate interface layer and is used for requesting to delete the application file, and returning information of successfully deleting the application file to the API intermediate interface layer.
5. The cloud application file version management system based on metadata as claimed in claim 1, wherein said API middle interface layer is configured to receive a request to build a data warehouse instruction, a request to execute a fixed application file version instruction, a request to call a history version instruction, a request to create a branch instruction, a request to delete a version instruction, and a request to merge a version instruction sent by a front end of a web page; the method is also used for forwarding the data warehouse ID, the fixed version success information, the metadata, the deletion success and the version information to the front end of the webpage; the method is also used for receiving an instruction for requesting an obs storage address, an instruction for requesting to store metadata, an instruction for requesting an obs cache address, an instruction for requesting to update metadata, an instruction for requesting to clear cache metadata and an obs storage address instruction for requesting to merge data in a version, which are sent by the cloud virtual machine; the method is also used for returning an obs storage address, an obs cache address, information of successfully clearing cache metadata and an obs storage address of data in a merged version to the cloud virtual machine; the method is also used for forwarding an instruction for requesting to establish a storage application file data warehouse to a version management system server, forwarding application file metadata generated by the instruction and an instruction for requesting to store the application file metadata, forwarding the generated updated application file metadata and an instruction for requesting to store the updated application file metadata, forwarding an instruction for requesting to execute a fixed version, forwarding an instruction for clearing cache metadata, analyzing a request call history version instruction and generating and sending a request call history version metadata, forwarding an instruction for requesting to create a branch, forwarding an instruction for requesting to delete a version, sending an instruction for requesting to pull all metadata of versions to be combined and forwarding an instruction for requesting to combine versions; the system is also used for receiving the data warehouse ID of the storage application file returned by the version management system server, the information of a successful fixed version, the information of successful clearing cache metadata, historical version metadata, new branch metadata, the information of successful deleting version, all the metadata of versions to be combined and the metadata of the version after combination; and the cloud file storage server is also used for sending an instruction for requesting to delete the application file to the cloud file storage server and receiving the information of successfully deleting the application file returned by the cloud file storage server.
6. The cloud application file version management system based on metadata as claimed in claim 1, wherein said version management system server is configured to receive an instruction for requesting to create a storage application file data repository, an instruction for generating application file metadata and requesting to store application file metadata, an instruction for generating updated application file metadata and requesting to store updated application file metadata, an instruction for requesting to execute a fixed version, an instruction for clearing cache metadata, an instruction for calling history version metadata, an instruction for requesting to create a branch, an instruction for requesting to delete a version, an instruction for requesting to pull all metadata of versions to be combined, an instruction for requesting to combine versions, and an instruction for requesting to combine versions, which are forwarded by an API intermediate interface layer; and the method is also used for returning the storage application file data warehouse ID, the information of a successful fixed version, the information of successful clearing cache metadata, historical version metadata, new branch metadata, the information of successful deleting version, all metadata of versions to be combined and metadata of the combined version to the API intermediate interface layer.
7. The cloud application file version management system based on metadata as claimed in claim 1, wherein all interaction information and all metadata between the front end of the webpage, the cloud virtual machine, the API middle interface layer, the version management system server and the cloud file storage server are in json or Protobuf data format.
8. The metadata-based cloud application file version management system of any of claims 1 to 7, wherein the application files are text-based application files and/or non-text-based application files within an industrial domain; each application file includes one or more documents that can be pinned to a separate new version when one or more changes in modifying document content, adding new documents, deleting documents occur within the application file.
9. A method for cloud application file version management by using the metadata-based cloud application file version management system according to any one of claims 1 to 8, comprising the steps of S1 to S4:
step S1: newly-built application file, which includes step S11-step S18:
step 11, one or more users log in to the front end of the webpage at the same time, and send out an instruction for requesting to newly build an application file through interface interaction;
step 12, the front end of the webpage receives instruction information of the newly built application file, sends a request for establishing a data warehouse of the stored application file to an API intermediate interface layer, and forwards the request to a version management server through the API intermediate interface layer;
step 13, the version management server returns the available data warehouse ID on the current server aiming at the request for establishing and storing the application file data warehouse forwarded by the intermediate interface layer, and the data warehouse ID forwards the web page front end where the user is located back through the API intermediate interface layer;
Step 14, after the front end of the webpage acquires the data warehouse ID, sending an instruction for requesting to start the application to the cloud virtual machine;
step 15, after the cloud virtual machine successfully starts the application, sending an instruction for requesting the obs storage address to an API intermediate interface layer; the API intermediate interface layer generates an obs storage key corresponding to the application file, and returns an available obs storage address to the cloud virtual machine;
step 16, automatically storing the application file or after receiving a storage instruction sent by a user by manually clicking a storage button at the front end of a webpage, sending an instruction for requesting to store the application file and the current application file to a cloud file storage server by the cloud virtual machine, and returning successful storage information to the cloud virtual machine by the cloud file storage server;
step 17, the cloud virtual machine returns information to the front end of the webpage, wherein the information comprises a successful storage message and an obs storage address;
step 18, the cloud virtual machine sends an instruction for requesting to store metadata to an API intermediate interface layer, and the API intermediate interface layer generates metadata corresponding to the current application file based on the data warehouse ID and then forwards and stores the metadata to a version management server;
step S2: editing an application file comprising steps 21-25:
step 21, after requesting to start an application file at the cloud virtual machine and performing editing operation through the front end of the webpage, a user sends an editing and modifying instruction to the cloud virtual machine, and after executing the editing and modifying instruction at the cloud virtual machine, the user generates a modified cache application file;
Step 22, the cloud virtual machine sends an instruction for requesting an obs cache address to an API intermediate interface layer; the API intermediate interface layer returns the currently available cache address to the cloud virtual machine;
step 23, after the cloud virtual machine successfully receives the cache address, sending an instruction for requesting to store the application file to a cloud file storage server, and returning storage success information to the cloud virtual machine by the cloud file storage server, wherein only a difference part between a record and a previous cache file or a historical version application file is stored when the cloud file storage server stores the storage success information;
step 24, the cloud virtual machine returns information to the front end of the webpage, wherein the information comprises a successful storage message and an obs storage address;
step 25, the cloud virtual machine sends an instruction for requesting to update metadata to an API intermediate interface layer, the API intermediate interface layer generates metadata corresponding to the edited and modified application file based on the data warehouse ID, and then forwards and saves the updated metadata to a version management server to replace historical metadata;
step S3: a fixed version comprising steps 31-38:
step 31, a user sends an instruction for requesting to fix the version of the current application file through the front end of the webpage, and the edited and modified application file is temporarily cached at the cloud virtual machine;
Step 32, after receiving the request instruction of the fixed version, the cloud virtual machine sends an instruction for requesting the obs storage address to an API intermediate interface layer, and the API intermediate interface layer returns the corresponding obs storage address to the cloud virtual machine;
step 33, after receiving the obs storage address, the cloud virtual machine stores the currently cached application file to the corresponding storage address of the cloud file storage server, and after successful storage, the cloud file storage server sends storage success information to the cloud virtual machine;
step 34, after the cloud virtual machine receives the information of successful storage, sending an instruction for clearing the cache metadata to an API intermediate interface layer, and sending an instruction for executing the clearing of the cache data to a version management server by the API intermediate interface layer for execution;
and 35, after the version management server successfully clears the cache data, returning cache clearing success information to an API intermediate interface layer, and forwarding the cache clearing success information to the cloud virtual machine by the API intermediate interface layer.
Step 36, after the cloud virtual machine receives the cache clearing success information, packaging and returning the storage success information and the obs storage address to the front end of the webpage;
step 37, after receiving the returned storage information, the front end of the web page requests to execute the instruction of the fixed version to the API intermediate interface layer, and forwards the instruction to the version management server through the intermediate layer to store the metadata of the application file under the current version;
Step 38, the version management server returns the success information of the fixed version, forwards the success information back to the front end of the webpage through the API intermediate interface layer, and prompts to inform the user;
step S4: managing application file versions, including one or more of steps S41 to S44:
step S41: a call history version, which includes step S411 to step S416:
step S411, the user sends an instruction for requesting to call a certain historical version of the application file to an API intermediate interface layer through the front end of the webpage, after the API intermediate interface layer analyzes the request instruction, the application file ID is obtained after searching, a corresponding request is sent to a version management server, and metadata corresponding to the historical version is requested to be called;
step S412, the version management server returns the metadata corresponding to the history version to the API intermediate interface layer, and the intermediate interface layer forwards the metadata to the front end of the webpage;
step S413, the front end of the webpage sends the metadata to the cloud virtual machine;
step S414, after the cloud virtual machine receives the metadata, according to the ID of the application file, sending an instruction for requesting the corresponding obs storage address of the application file to an API intermediate interface layer, and returning the obs storage address to the cloud virtual machine by the intermediate interface layer;
step S415, after receiving the obs storage address, the cloud virtual machine sends a request for calling an application file in the storage address to a cloud file storage server, and the cloud file storage server downloads a corresponding application file and transmits the corresponding application file to the cloud virtual machine;
Step S416, the cloud virtual machine opens the corresponding application file, and after the interface is updated, the corresponding application file is transmitted back to the front end of the webpage and displayed to the user; step S42: creating a branch comprising step S421-step S426:
step S421, the user sends an instruction for requesting to create branches to an API intermediate interface layer through the front end of the webpage, after the API intermediate interface layer analyzes the request instruction, the application file ID and father version ID information are obtained after searching, a new branch ID is generated, a corresponding request is sent to a version management server, and after the version management server checks the editing authority of the user, metadata corresponding to the new branches are generated;
step S422, the version management server returns the metadata of the new branch to an API intermediate interface layer, and the intermediate interface layer forwards the metadata to the front end of the webpage;
step S423, the user sends an instruction for requesting to call the parent version application file based on the new branch to the cloud virtual machine through the front end of the webpage, wherein the instruction contains the parent version application file information based on the branch to be newly created;
step S424, the cloud virtual machine sends an instruction for requesting the obs storage address to an API intermediate interface layer according to the application file of the history version, and the API intermediate interface layer returns the corresponding obs storage address to the cloud virtual machine;
Step S425, after receiving the obs storage address, the cloud virtual machine sends a request for calling the application file of the father version in the storage address to a cloud file storage server, and the cloud file storage server downloads the corresponding application file and transmits the application file to the cloud virtual machine;
step S426, the cloud virtual machine opens the application file corresponding to the father version, and after the interface is updated, the application file is transmitted back to the front end of the webpage and displayed to the user, and the user is allowed to enter an editing state;
step S43: delete version, it includes step S431-step S438:
step S431, the user sends a command for requesting to delete the version to the API middle interface layer through the front end of the webpage, wherein the request command comprises an application file name and a version name to be deleted;
step S432, after receiving the deletion request instruction, the version management server checks the deletion authority of the user, deletes the metadata of the version to be deleted at the server side, and returns the deletion success information to the API intermediate interface layer;
step S433, the API intermediate interface layer searches the corresponding obs storage address according to the version ID to be deleted and sends an instruction for requesting to delete the application file to the cloud file storage server;
in step S434, after the cloud file storage server successfully deletes the history version, the cloud file storage server returns the deletion success information to the API intermediate interface layer, and at the same time, the API intermediate interface layer parses the latest version information, and sends the latest version metadata and the deleted version information to the front end of the web page, where the latest version is the parent version of the deleted history version.
Step S435, the front end of the webpage sends an instruction for requesting to clear the deleted version cache data to the cloud virtual machine according to the received version information, and simultaneously, the front end of the webpage sends an instruction for calling the current latest version and the corresponding metadata thereof to the cloud virtual machine;
step S436, after receiving the metadata of the current latest version, the cloud virtual machine sends an instruction for requesting the obs storage address to an API intermediate interface layer according to the application file ID, and the API intermediate interface layer returns the obs storage address to the cloud virtual machine;
step S437, after the cloud virtual machine receives the obs storage address, a request for calling the application file in the storage address is sent to the cloud file storage server, the cloud file storage server downloads the corresponding application file and transmits the corresponding application file to the cloud virtual machine;
step S438, the cloud virtual machine opens the application file of the current latest version, and the interface is updated and then transmitted back to the front end of the webpage to be displayed to the user;
step S44: a merged version comprising step S441-step S449:
step S441, the user sends an instruction for requesting to merge versions to an API intermediate interface layer at the front end of the webpage, wherein the instruction comprises name information of the versions to be merged, and after the API intermediate interface layer analyzes the instruction, the user sends a request for pulling metadata of all the versions to be merged to a version management server;
Step S442, the version management server returns the metadata of all versions to be combined to the API intermediate interface layer, and forwards the metadata back to the front end of the webpage through the API intermediate interface layer;
step S443, the front end of the webpage is provided with a version analysis module, conflict parts among different versions are analyzed according to metadata of the versions to be merged, comparison results of the different versions are displayed at an interface, and the user is waited to select the version content to be reserved and merged in the conflict parts;
step S444, after the user finishes screening the merging conflict part through the front end of the webpage, the front end of the webpage sends an instruction for requesting to merge the version to an API intermediate interface layer, and the API intermediate interface layer forwards the merging instruction to a version management server to generate metadata corresponding to the merged version;
step S445, the version management server returns the metadata of the merged version to the API intermediate interface layer, and returns to the front end of the web page via the API intermediate interface layer;
step S446, the front end of the webpage sends the merged version metadata to the cloud virtual machine;
step S447, the cloud virtual machine sends an obs storage address of the data in the request merge version to the API intermediate interface layer, and the API intermediate interface layer returns an address to the cloud virtual machine;
step S448, the cloud virtual machine sends the version file data after request combination to a cloud file storage server according to the returned obs storage address, and the cloud file storage server downloads and transmits the corresponding file data to the cloud virtual machine;
Step 449, the cloud virtual machine finishes loading, displays the state of the combined version file, updates the interface, transmits the updated interface back to the front end of the webpage, and displays the updated interface to the user.
10. The method of claim 9, wherein in step 18, the application file metadata to be stored includes information comprising: metadata repository ID, application file name, application file ID, primary branch name, primary branch ID, obs storage key, creation user ID, creation time; in step 25, the metadata requested to be updated includes updated information: applying the obs cache key of all documents in the file, modifying the user ID and the latest modification time; in step 37, the executing the fixed version instruction includes: the method comprises the steps of storing keys of the obs of all documents in an application file of a current version to be fixed, branch names, branch IDs, version names, version IDs, father version names, father version IDs, version remark information, version creation user IDs and version creation time of the application file; in step 412, the metadata returned in the version management server includes the following information: the method comprises the steps of an application file name, an application file ID, an obs storage key of all documents in a version application file to be called, a branch name, a branch ID, a version name, a version ID, a father version name, a father version ID, version remark information, a version creation user and a version creation time of the application file; in step S422, the new branch metadata returned by the version management system server includes: application file name, application file ID, newly created branch name, newly created branch ID, obs storage key of newly created branch, branch creation user, and branch creation time; in step S442, metadata returned by the version management system server includes: application file name, application file ID and all version information to be combined; the all version information to be combined comprises: the keys are stored corresponding to the version name, version ID, branch name, and the obs of all documents in the version for each version.
CN202311192344.2A 2023-09-15 2023-09-15 Cloud application file version management system based on metadata Active CN117270943B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311192344.2A CN117270943B (en) 2023-09-15 2023-09-15 Cloud application file version management system based on metadata

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311192344.2A CN117270943B (en) 2023-09-15 2023-09-15 Cloud application file version management system based on metadata

Publications (2)

Publication Number Publication Date
CN117270943A true CN117270943A (en) 2023-12-22
CN117270943B CN117270943B (en) 2024-07-19

Family

ID=89200055

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311192344.2A Active CN117270943B (en) 2023-09-15 2023-09-15 Cloud application file version management system based on metadata

Country Status (1)

Country Link
CN (1) CN117270943B (en)

Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101206564A (en) * 2006-12-20 2008-06-25 鸿富锦精密工业（深圳）有限公司 Document version pipe control interface arrangement and method
US20160034267A1 (en) * 2014-08-01 2016-02-04 Sap Se Lightweight application deployment
CN107404520A (en) * 2017-07-20 2017-11-28 郑州云海信息技术有限公司 A kind of management method and system based on cloud management platform
US20180275881A1 (en) * 2017-03-27 2018-09-27 Commvault Systems, Inc. Creating local copies of data stored in online data repositories
CN110609779A (en) * 2019-08-20 2019-12-24 腾讯科技（深圳）有限公司 Data processing method and device, electronic equipment and computer readable storage medium
CN111008036A (en) * 2019-12-02 2020-04-14 北京仿真中心 Structural data version management system and method based on GIT
CN111104125A (en) * 2019-11-19 2020-05-05 泰康保险集团股份有限公司 Intelligent integrated version management method, device, medium and electronic equipment
US10853316B1 (en) * 2017-10-31 2020-12-01 Amazon Technologies, Inc. File versioning for content stored in a cloud computing environment
WO2021217868A1 (en) * 2020-04-30 2021-11-04 平安科技（深圳）有限公司 Git-based project version release method and apparatus, device, and medium
CN113760354A (en) * 2021-09-07 2021-12-07 广东电网有限责任公司 Method and device for managing and controlling body information version of dispatching automation system
CN114237688A (en) * 2021-12-06 2022-03-25 网易（杭州）网络有限公司 Branch version merging method, device and system and electronic equipment
CN114265814A (en) * 2022-03-01 2022-04-01 天津安锐捷技术有限公司 Data lake file system based on object storage
CN115238654A (en) * 2022-07-14 2022-10-25 思乐格计算技术(南京)有限公司 Multi-user online real-time collaborative editing system
CN115422598A (en) * 2022-11-08 2022-12-02 壹仟零壹艺网络科技(北京)有限公司 CAD drawing version management method based on GIT system
CN115630345A (en) * 2022-10-24 2023-01-20 广东电网有限责任公司 Business management system
CN116466983A (en) * 2023-03-15 2023-07-21 中银金融科技有限公司 Code management device, method, storage medium and electronic device
CN116578331A (en) * 2023-05-11 2023-08-11 浪潮卓数大数据产业发展有限公司 Service version management method, device and medium based on Web interface

Patent Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101206564A (en) * 2006-12-20 2008-06-25 鸿富锦精密工业（深圳）有限公司 Document version pipe control interface arrangement and method
US20160034267A1 (en) * 2014-08-01 2016-02-04 Sap Se Lightweight application deployment
US20180275881A1 (en) * 2017-03-27 2018-09-27 Commvault Systems, Inc. Creating local copies of data stored in online data repositories
CN107404520A (en) * 2017-07-20 2017-11-28 郑州云海信息技术有限公司 A kind of management method and system based on cloud management platform
US10853316B1 (en) * 2017-10-31 2020-12-01 Amazon Technologies, Inc. File versioning for content stored in a cloud computing environment
CN110609779A (en) * 2019-08-20 2019-12-24 腾讯科技（深圳）有限公司 Data processing method and device, electronic equipment and computer readable storage medium
CN111104125A (en) * 2019-11-19 2020-05-05 泰康保险集团股份有限公司 Intelligent integrated version management method, device, medium and electronic equipment
CN111008036A (en) * 2019-12-02 2020-04-14 北京仿真中心 Structural data version management system and method based on GIT
WO2021217868A1 (en) * 2020-04-30 2021-11-04 平安科技（深圳）有限公司 Git-based project version release method and apparatus, device, and medium
CN113760354A (en) * 2021-09-07 2021-12-07 广东电网有限责任公司 Method and device for managing and controlling body information version of dispatching automation system
CN114237688A (en) * 2021-12-06 2022-03-25 网易（杭州）网络有限公司 Branch version merging method, device and system and electronic equipment
CN114265814A (en) * 2022-03-01 2022-04-01 天津安锐捷技术有限公司 Data lake file system based on object storage
CN115238654A (en) * 2022-07-14 2022-10-25 思乐格计算技术(南京)有限公司 Multi-user online real-time collaborative editing system
CN115630345A (en) * 2022-10-24 2023-01-20 广东电网有限责任公司 Business management system
CN115422598A (en) * 2022-11-08 2022-12-02 壹仟零壹艺网络科技(北京)有限公司 CAD drawing version management method based on GIT system
CN116466983A (en) * 2023-03-15 2023-07-21 中银金融科技有限公司 Code management device, method, storage medium and electronic device
CN116578331A (en) * 2023-05-11 2023-08-11 浪潮卓数大数据产业发展有限公司 Service version management method, device and medium based on Web interface

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
孙寒玉;顾春华;万锋;杨巍巍;周冀平;陈煌;: "一种基于OpenStack的云应用开发框架", 华东理工大学学报(自然科学版), no. 02, 30 April 2015 (2015-04-30) *
王朝凯;范永璞;印海洋;李岩;周金桥;余秋衡;: "一种基于Git的智能变电站二次回路信息模型的版本管理系统", 电气技术与经济, no. 06, 20 December 2019 (2019-12-20) *
郑涔;李小勇;: "一种适用于协同设计环境的分布式存储系统", 微型电脑应用, no. 05, 20 May 2011 (2011-05-20) *

Also Published As

Publication number Publication date
CN117270943B (en) 2024-07-19

Similar Documents

Publication Publication Date Title
US7925632B2 (en) Transient data facility for database applications
US9423920B2 (en) System and method for modifying user interface elements
JP3489123B2 (en) Application binding method
US9952856B2 (en) Deploying mobile applications in a collaborative cloud environment
KR101377311B1 (en) Integrating charts in documents
CN112328212A (en) Rapid development platform based on separation of front end and rear end of engine mode and use method thereof
US10726040B2 (en) Lossless conversion of database tables between formats
US7475075B2 (en) Integration rich client views in server presentations
CN107943453B (en) Method and system for realizing user-defined plan task of operation and maintenance system
US8572102B2 (en) Method and system for making dynamic graphical web content searchable
CA2360645C (en) Dynamic generic framework for distributed tooling
US20120130906A1 (en) Deployment mechanism for non-versioning business process artifacts
CN115292073B (en) Method for sending android application file on Linux platform
CN111984280B (en) Container compatibility, upgrading method, device, equipment and storage medium
CN117270943B (en) Cloud application file version management system based on metadata
CN110175309B (en) Native terminal resource pool management system and method for mobile application hybrid development
CN117251197A (en) Method for realizing management of Submodule item Git based on node. Js
CN110941471A (en) Method and device for internationalizing basic data of software system
US20120221507A1 (en) Declarative update to a live system
JPH1173459A (en) Work flow management system and method for operating document management
CN100407144C (en) Method and device for starting sub module in application program
JP4908539B2 (en) Workflow processing apparatus, program, and method
CN116501376B (en) Decoupling method, system and device based on configuration instant trigger task
JPH0922348A (en) Program preparing method and program managing method
CN114327414B (en) Method for implementing trigger capable of being plugged in and unplugged from node and computer readable storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant