Work remote version management method, electronic device and computer storage medium

Abstract

The present application discloses a method for remote version management of works, an electronic device, and a computer storage medium. The method for remote version management of works includes: dividing the local version data of the work into multiple data files and sending them to a Git server in sequence, wherein the multiple data files include a version record file; receiving file identification numbers corresponding to the multiple data files, wherein the file identification numbers are generated by the Git server according to the multiple data files; when the version record file identification number corresponding to the version record file is received, remote version information is generated according to the version record file identification number. Through the technical solution of the present application, a remote version management function is provided for animation programming software, which facilitates users to share their works, and the method of sending a single data file can effectively improve the fault tolerance rate of data sending.

Description

Technical Field

[0001] The present application relates to the technical field of animation programming software development, and in particular to a remote version management method for works, an electronic device, and a computer storage medium. Background Art

[0002] With the development of computer technology, more and more people are beginning to learn programming. For children, some programming enthusiasts and beginners, there are many easy-to-learn animation programming software on the market. The entry threshold for using animation programming software to create works is low, the software is easy to operate and it is very interesting.

[0003] The process of creating works with animation programming software is long and phased. After multiple version edits, users may save multiple versions locally and need to upload the latest version data to the cloud to share with other users. General animation programming software directly packages the version data of the work and then sends the package to the cloud for remote storage. However, this method of sending version data in the form of a package has a large data transmission volume and is prone to low transmission fault tolerance. Summary of the invention

[0004] In order to solve the above technical problems, the present application provides a method for remote version management of works, an electronic device and a computer storage medium.

[0005] In a first aspect, the present application proposes a method for remote version management of a work, the method comprising:

[0006] Dividing the local version data of the work into multiple data files, and sending the multiple data files to the Git server in sequence, the multiple data files including a version record file;

[0007] Receive file identification numbers corresponding to a plurality of data files, wherein the file identification numbers are generated by the Git server according to the plurality of data files;

[0008] When the version record file identification number corresponding to the version record file is received, remote version information is generated according to the version record file identification number.

[0009] In a second aspect, the present application proposes an electronic device, comprising a memory, a processor, and program data stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned method for remote version management of works when executing the program data.

[0010] In a third aspect, the present application proposes a computer storage medium, which is used to store program data. When the program data is executed by a processor, it is used to implement the steps of the above-mentioned method for remote version management of works.

[0011] Different from the prior art, the method of the present application is: the local version data of the work is divided into multiple data files and sent to the Git server in sequence, the multiple data files include a version record file; the file identification numbers corresponding to the multiple data files are received, and the file identification numbers are generated by the Git server according to the multiple data files; when the version record file identification number corresponding to the version record file is received, the remote version information is generated according to the version record file identification number. Through the technical solution of the present application, a remote version management function is provided for animation programming software, which is convenient for users to share their works, and the method of sending a single data file can effectively improve the fault tolerance rate of data transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0013] Figure 1 This is a flowchart of an embodiment of a method for remote version management of works provided by this application;

[0014] Figure 2 It is a structural schematic diagram of an embodiment of an electronic device provided by the present application;

[0015] Figure 3 It is a structural diagram of an embodiment of a computer storage medium provided by the present application. DETAILED DESCRIPTION

[0016] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0017] The remote version management method of the work of the present application is applied to an electronic device, which can be specifically a user terminal, and the user terminal can be an electronic device such as a smart phone, a computer, a tablet computer, a smart wearable device, etc.

[0018] See also Figure 1 , Figure 1This is a flowchart of an embodiment of a remote version management method for works provided by this application, which specifically includes the following steps:

[0019] S101: Divide the local version data of the work into multiple data files, and send the multiple data files to the Git server in sequence, wherein the multiple data files include a version record file.

[0020] Among them, animation programming software is installed on the user terminal, and the user uses the animation programming software to create works through the user terminal. During the creation process or after the creation is completed, the user can save the current work locally through the user terminal and upload it to the Git server for remote storage and share it with other users.

[0021] Specifically, the user can generate a remote version saving instruction for the work by clicking the upload sharing button in the animation programming software. When the user terminal receives the remote version saving instruction for the work, the user terminal extracts the current local version data of the work and divides it into multiple separate data files, and then sends the multiple data files to the Git server in sequence. The user terminal of this embodiment divides the current local version data into multiple separate data files, which is conducive to reducing the real-time transmission volume during the transmission process and improving the fault tolerance rate of the transmission process. Among them, the local version data of the work is the version composition data recording the work under the local server. The user can directly load the local version data from the local server through the animation programming software, so as to display the editing status of the work under the version in the animation programming software.

[0022] The multiple data files include a version record file, and in each complete local version data transmission process, the version record file is sent to the Git server as the last data file.

[0023] The Git server (distributed version control Git server) of this embodiment is a server or server cluster equipped with Git (distributed version control system). Git is an open source distributed version control system that can efficiently handle version management of projects from very small to very large.

[0024] In some embodiments, the step of sending multiple data files in sequence to the Git server includes: obtaining the previous remote version data of the work; comparing the previous remote version data with the current local version data to obtain a target data file, the target data file being a data file in the current local version data that is different from the previous remote version data; and sending the target data files in sequence to the Git server.

[0025] Specifically, in order to reduce the amount of data transmission, avoid sending the same data files repeatedly, and improve data transmission efficiency, in the process of dividing the local version data of the work into multiple data files and sending the multiple data files in sequence to the Git server, the previous remote version data of the work is first obtained, and the previous remote version data is compared with the current local version data of the work to obtain the data files in the current local version data that are different from the previous remote version data as the target data files, and only these target data files are sent to the Git server, and other data files in the current local version data that are the same as the previous remote version data are no longer sent repeatedly. The different data files involved in this embodiment include data files with changed data information and data files that are newly added and reduced in the current local version data relative to the previous remote version data. The previous remote version is the remote version that the user last uploaded to the Git server.

[0026] In a specific embodiment, the steps of obtaining the previous remote version data of the work, comparing the previous remote version data with the current local version data, and obtaining the target data file include: obtaining the hash value corresponding to the previous remote version data file of the work; performing hash calculation on the current local version data file to obtain the hash value corresponding to the current local version data file; comparing the hash value corresponding to the previous remote version data file with the hash value corresponding to the current local version data file one by one, and obtaining the data file in the current local version data that is different from the previous remote version data as the target data file.

[0027] Since the hash value and the corresponding multiple data files are in a one-to-one correspondence, and for data files with exactly the same data information, the corresponding hash value is unique. When the data information of the data file changes, the corresponding generated hash value will also change. Therefore, by mapping the corresponding data file with the hash value, it is possible to monitor whether the data file has changed. Specifically, in the process of comparing the hash value corresponding to the previous remote version data file with the hash value corresponding to the current local version data file one by one, for data files that already exist in both versions and have the same name, if the hash values ​​corresponding to the two versions are different, it means that the data information of the data file in the current local version has changed and needs to be sent to the Git server for updating. If the hash values ​​corresponding to the two versions are the same, it means that the data information of the data file in the current local version has not changed, and the data file does not need to be sent to the Git server again; for data files that are newly added in the current local version data relative to the previous remote version data, they need to be sent to the Git server to be added as data files of the current remote version; for data files that are reduced in the current local version data relative to the previous remote version data, it means that the data file in the current local version data has been deleted, and then it is only necessary to send the information that the data file has been deleted to the Git server. Accordingly, when the current remote version data is generated, the data file in the current remote version data will also be deleted.

[0028] In some embodiments, the step of sending multiple data files of the work to the Git server in sequence also includes: when any one of the data files fails to be sent during the process of sending the multiple data files in sequence to the Git server, the sending process is interrupted, and when sending again, the multiple data files that have not been sent are sent in sequence starting from the current data file that failed to be sent.

[0029] Specifically, in order to reduce the amount of data transmission, avoid sending the same data files repeatedly, and improve data transmission efficiency, in the process of dividing the local version data of the work into multiple data files and sending them to the Git server in sequence, when any of the data files fails to be sent, the entire version data sending process is interrupted, and the current data file that failed to be sent can be used as a breakpoint. When the version data is sent again, starting from the breakpoint, the current data file that failed to be sent will be used as the first data file, and multiple data files that have not been sent will be sent in sequence, and the data files that have been successfully sent before the breakpoint will no longer be sent repeatedly.

[0030] In a specific embodiment, the process of sending multiple data files of a work to a Git server in sequence also includes: generating prompt information according to the progress of sending the multiple data files. Specifically, the prompt information includes the name and progress of the data file currently being sent, the sending status, etc. Through the prompt information, the user can obtain the status of the data file transmission process in real time.

[0031] S102: Receive file identification numbers corresponding to multiple data files, where the file identification numbers are generated by the Git server based on the multiple data files.

[0032] After receiving multiple data files sent by the user, the Git server generates a corresponding unique file identification number according to each data file, stores the multiple data files according to the file identification number, and returns the file identification number to the user.

[0033] In some embodiments, the Git server generates a corresponding unique file identification number according to each data file, including the steps of: the Git server uses a hash algorithm to calculate each data file to generate a hash value corresponding to each data file, and generates a file identification number corresponding to each data file according to each hash value.

[0034] Specifically, the Git server receives multiple data files sent sequentially by the user end, calculates each data file through a hash algorithm, and obtains a corresponding hash value. Then, file identification numbers corresponding to multiple files are generated according to the multiple hash values, and the file identification numbers can be in the form of digital IDs. At this time, the data files are stored in one storage space or distributed in multiple storage spaces, and the file identification number records the storage address of the corresponding data file, so that the Git server or the user end can quickly locate the corresponding data file through the file identification number.

[0035] S103: When a version record file identification number corresponding to the version record file is received, remote version information is generated according to the version record file identification number.

[0036] The user receives and stores the file identification number returned by the Git server. When the user receives the version record file identification number corresponding to the version record file, it indicates that all data files of the local version data have been uploaded to the Git server. The user generates remote version information based on the received version record file identification number. The remote version information includes the remote version number and the remote version address information. Other users can load the remote version data of the work through the remote version address information. The user can also switch between the local version and the remote version at will, and synchronize at any time.

[0037] In a specific embodiment, the step of generating remote version information according to the version record file identification number includes: obtaining file identification numbers of multiple data files corresponding to the current local version data according to the version record file identification number, and generating the current remote version information according to the multiple file identification numbers.

[0038] Specifically, when the version record file identification number corresponding to the version record file is received, it can be determined based on the version record file identification number that all data files of the current local version data have been uploaded. At this time, the file identification numbers of multiple data files corresponding to the current local version data are obtained, and the multiple data files and version record files corresponding to the current local version data are used as remote version data, and the current remote version information is generated based on multiple file identification numbers.

[0039] In an embodiment of the present application, the local version data of the work is divided into multiple data files and sent to the Git server in sequence, the multiple data files include a version record file; the file identification numbers corresponding to the multiple data files are received, and the file identification numbers are generated by the Git server according to the multiple data files; when the version record file identification number corresponding to the version record file is received, the remote version information is generated according to the version record file identification number. The remote version management method of the work provided by the present application divides the local version data into multiple separate data files, and sends the multiple separate data files to the Git server in sequence to generate remote version information, thereby providing a remote version management function for animation programming software, facilitating users to share their works, and effectively improving the fault tolerance rate of data transmission.

[0040] In order to implement the above-mentioned remote version management method of works, this application also provides an electronic device, please refer to Figure 2 , Figure 2 It is a structural schematic diagram of an embodiment of an electronic device provided by the present application.

[0041] like Figure 2 As shown, the electronic device 200 of this embodiment includes a processor 21 , a memory 22 , an input / output device 23 , and a bus 24 .

[0042] The processor 21, memory 22, and input / output device 23 are respectively connected to the bus 24. The memory 22 stores program data, and the processor 21 is used to execute the program data to implement the remote version management method of works described in the above embodiment.

[0043] In this embodiment, the processor 21 may also be referred to as a CPU (Central Processing Unit). The processor 21 may be an integrated circuit chip having signal processing capabilities. The processor 21 may also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. A general-purpose processor may be a microprocessor or the processor 21 may also be any conventional processor, etc.

[0044] The present application also provides a computer storage medium, such as Figure 3 As shown, the computer storage medium 300 is used to store program data 31. When the program data 31 is executed by the processor, it is used to implement the method described in the embodiment of the remote version management method of works provided in this application.

[0045] The methods involved in the embodiments of the remote version management method of works provided by this application, when implemented in the form of software functional units and sold or used as independent products, can be stored in a device, such as a computer-readable storage medium. Based on such an understanding, the technical solution of this application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of this application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0046] The above description is only an implementation method of the present application, and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly used in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for remote version management of works, characterized in that: The method comprises: Divide the local version data of the work into multiple data files, and send the multiple data files to the Git server in sequence, wherein the multiple data files include a version record file; Receive file identification numbers corresponding to a plurality of data files, wherein the file identification numbers are generated by the Git server according to the plurality of data files; When receiving the version record file identification number corresponding to the version record file, generating remote version information according to the version record file identification number; The step of sending the multiple data files in sequence to the Git server comprises: Obtaining the previous remote version data of the work, comparing the previous remote version data with the current local version data, and obtaining a target data file, wherein the target data file is a data file in the current local version data that is different from the previous remote version data; Sending the target data files to the Git server in sequence; The step of generating remote version information according to the version record file identification number comprises: The file identification numbers of multiple data files corresponding to the current local version data are obtained according to the version record file identification number, and the current remote version information is generated according to the multiple file identification numbers.

2. The method for remote version management of works according to claim 1, characterized in that: The step of sending the plurality of data files sequentially to the Git server further includes: The version record file is sent to the Git server as the last data file.

3. The method for remote version management of works according to claim 1, characterized in that: The Git server calculates each data file using a hash algorithm to generate a hash value corresponding to each data file, and generates a file identification number corresponding to each data file according to each hash value.

4. The method for remote version management of works according to claim 1, characterized in that: The step of obtaining the previous remote version data of the work, comparing the previous remote version data with the current local version data, and obtaining the target data file includes: Obtaining a hash value corresponding to a data file of a previous remote version of the work; Performing hash calculation on the current local version data file to obtain a hash value corresponding to the current local version data file; The hash value corresponding to the previous remote version data file and the hash value corresponding to the current local version data file are compared one by one, and a data file in the current local version data that is different from the previous remote version data is obtained as the target data file.

5. The method for remote version management of works according to claim 1, characterized in that: The step of sending the plurality of data files sequentially to the Git server further includes: When the multiple data files are sent to the Git server in sequence, if any one of the data files fails to be sent, the sending process is interrupted. When sending again, the multiple data files that have not been sent are sent in sequence starting from the current data file that failed to be sent.

6. The method for remote version management of works according to claim 1, characterized in that: The step of sending the plurality of data files sequentially to the Git server further includes: Prompt information is generated according to the progress of sending the multiple data files.

7. An electronic device, characterized in that: The electronic device includes a memory, a processor, and program data stored in the memory and executable on the processor. When the processor executes the program data, the steps of the remote version management method for works described in any one of claims 1 to 6 are implemented.

8. A computer storage medium, characterized in that: The computer storage medium is used to store program data, and when the program data is executed by the processor, it is used to implement the steps of the remote version management method of works as described in any one of claims 1 to 6.

Images