A version management method, device and equipment of a graphical programming file

Abstract

The application provides a version management method, device and equipment of a graphical programming file, and relates to the technical field of file version management. The method comprises the following steps: obtaining editing information of the graphical programming file, wherein the editing information comprises role creation and / or modification; generating a role storage object and / or a data storage object according to the editing information, wherein the role storage object records original data of a newly created role, and the data storage object records differential data patches generated based on role modification contents; and generating file version submission information according to the role storage object and / or the data storage object and role index information, which can effectively reduce the version data of the graphical programming file that needs to be saved, improve the saving efficiency of the graphical programming file, and improve the tracking efficiency and accuracy of the graphical programming file.

Description

Technical Field

[0001] This application relates to the field of file version management technology, and in particular to a method, apparatus and device for version management of graphical programming files. Background Technology

[0002] Graphical programming transforms program instructions into "building blocks." Users don't need to type code or memorize any programming instructions; they simply drag and drop these blocks to connect them, enabling convenient programming and the rapid creation of animations, games, interactive programs, and more. Therefore, graphical programming, with its simplicity, support for all programming knowledge, support for complex data structures, and support for object-oriented and modular programming, allows for the integration of more functionalities into graphical programming through simple development. This enables more software developers to use graphical programming to implement code functionalities, simplifying and improving software development efficiency.

[0003] However, most current graphical programming systems lack version management for graphical programming files, or only use a linear management method for version management. Every time a graphical programming file is modified, such as moving a block, a complete copy of the modified graphical programming file needs to be serialized and saved to the database, resulting in low file saving efficiency and large data redundancy. Summary of the Invention

[0004] This application provides a method, apparatus, and device for version management of graphical programming files, which can effectively reduce the version data of graphical programming files that need to be saved, improve the saving efficiency of graphical programming files, and improve the tracking efficiency and accuracy of graphical programming files.

[0005] In a first aspect, this application provides a version management method for a graphical programming file, comprising: obtaining editing information of the graphical programming file, the editing information including the creation and / or modification of roles; generating a role storage object and / or a data storage object based on the editing information, the role storage object recording the original data of the newly created role, and the data storage object recording differential data patches generated based on the modifications to the role; generating file version submission information based on the role storage object and / or the data storage object, and role index information, the role index information including the index address of the role.

[0006] This embodiment of the application obtains the editing information of the graphical programming file and generates, based on the editing information, a data storage object that records the original data role of the newly created role and / or a data storage object that records the differential data patch generated based on the modification content of the role. Then, based on the role storage object, the data storage object, and the role index information of the graphical programming file, file version submission information is generated. It does not need to save the entire graphical programming file, but only saves the data storage object generated based on the newly created role and / or the data storage object generated based on the modified role, as well as the file version submission information generated based on the role index information of the graphical programming file. This greatly reduces the version data of the graphical programming file that needs to be saved. By recording the changes of the role through incremental data storage objects, the modification of the role in the graphical programming file can be tracked quickly and effectively, improving the tracking efficiency and accuracy of the graphical programming file and providing a better user experience.

[0007] In an optional approach provided in the first aspect, the generation of the role storage object and / or data storage object based on the aforementioned editing information includes:

[0008] When the above editing information involves modifications to a character, the modified content of the character is determined according to the differential algorithm, and a differential data patch is generated.

[0009] Obtain the version identifier information and index address of the modified character. The version identifier information includes the original version identifier and the modified version identifier of the character.

[0010] Based on the version identification information, the index address, and the differential data patch, the data storage object is generated.

[0011] In another alternative approach provided in the first aspect, the aforementioned file version commit information includes a version data list, and the generation of version commit information based on the aforementioned role storage object and / or the aforementioned data storage object, and role index information, includes:

[0012] Obtain the index address of the role in the above data storage object;

[0013] Based on the index address of the role in the above data storage object, determine the role index tree address of the graphical programming file to which the above data storage object belongs;

[0014] Based on the above role index tree address, determine the current version information of the graphical programming file to which the above data storage object belongs;

[0015] Based on the current version information above, determine the version information to be modified;

[0016] Update the commit list of the above versions based on the modified version information.

[0017] In another alternative approach provided in the first aspect, the aforementioned file version commit information includes file commit records, and the generation of version commit information based on the aforementioned role storage object and / or the aforementioned data storage object, and role index information, includes:

[0018] Based on the aforementioned role storage object and role index information, generate a file commit record; or:

[0019] Based on the aforementioned data storage objects and role index information, generate a file commit record; or:

[0020] Based on the aforementioned role storage object, the aforementioned data storage object, and the aforementioned role index information, a file commit record is generated.

[0021] In another alternative approach provided in the first aspect, after generating the file version submission information based on the aforementioned role storage object and / or the aforementioned data storage object, and the role index information, the method further includes:

[0022] The above file version submission information is sent to the cloud server. The cloud server saves the above file version submission information to the graphical programming file corresponding to the above role index information based on the role index information in the above file version submission information.

[0023] In another alternative approach provided in the first aspect, after generating the file version submission information based on the aforementioned role storage object and / or the aforementioned data storage object, and the role index information, the method further includes:

[0024] Obtain file viewing request information, which includes a first version identifier, which is the version identifier of the graphical programming file to be viewed;

[0025] Based on the first version identifier mentioned above, obtain the last saved file version submission information of the graphical programming file mentioned above.

[0026] Based on the above file version submission information, obtain the role data of the graphical programming file corresponding to the above first version identifier. The role data includes role storage objects and data storage objects.

[0027] Based on the aforementioned role data, the graphical programming file corresponding to the first version identifier is synthesized and displayed in the graphical programming tool.

[0028] In another alternative approach provided in the first aspect, after generating the file version submission information based on the aforementioned role storage object and / or the aforementioned data storage object, and the role index information, the method further includes:

[0029] Obtain version rollback request information, which includes a second version identifier, which is the version identifier of the graphical programming file for which rollback is requested.

[0030] Based on the differential algorithm, the differential data of the graphical programming file corresponding to the second version identifier and the graphical programming file corresponding to the third version identifier are determined. The third version identifier is the version identifier of the last saved graphical programming file.

[0031] Based on the determined differential data, the graphical programming file corresponding to the second version identifier is restored, and a version backtracking record is generated. The version backtracking record is used to record the backtracking operation of the graphical programming file.

[0032] Secondly, this application provides a graphical programming file version management device, comprising:

[0033] The editing information acquisition unit is used to acquire the editing information of the aforementioned graphical programming file, including the creation and / or modification of characters;

[0034] The storage object generation unit is used to generate a character storage object and / or a data storage object based on the above editing information. The character storage object records the original data of the newly created character, and the data storage object records differential data patches generated based on the character's modification content.

[0035] The file version submission information generation unit is used to generate file version submission information based on the aforementioned role storage object and / or the aforementioned data storage object, as well as role index information, wherein the aforementioned role index information includes the index address of the role.

[0036] In an alternative approach provided in the second aspect, the aforementioned storage object generation unit is used for:

[0037] When the above editing information involves modifications to a character, the modified content of the character is determined according to the differential algorithm, and a differential data patch is generated.

[0038] Obtain the version identifier information and index address of the modified character. The version identifier information includes the original version identifier and the modified version identifier of the character.

[0039] Based on the version identification information, the index address, and the differential data patch, the data storage object is generated.

[0040] In another alternative approach provided in the second aspect, the aforementioned file version commit information includes a version data list, and the aforementioned file version commit information generation unit is used for:

[0041] Obtain the index address of the role in the above data storage object;

[0042] Based on the index address of the role in the above data storage object, determine the role index tree address of the graphical programming file to which the above data storage object belongs;

[0043] Based on the above role index tree address, determine the current version information of the graphical programming file to which the above data storage object belongs;

[0044] Based on the current version information above, determine the version information to be modified;

[0045] Update the commit list of the above versions based on the modified version information.

[0046] In another alternative approach provided in the second aspect, the aforementioned file version commit information includes file commit records, and the aforementioned file version commit information generation unit is further used for:

[0047] Based on the aforementioned role storage object and role index information, generate a file commit record; or:

[0048] Based on the aforementioned data storage objects and role index information, generate a file commit record; or:

[0049] Based on the aforementioned role storage object, the aforementioned data storage object, and the aforementioned role index information, a file commit record is generated.

[0050] In another alternative embodiment provided in the second aspect, the aforementioned apparatus further includes:

[0051] The file version submission information sending unit is used to send the file version submission information to the cloud server. The cloud server saves the file version submission information to the graphical programming file corresponding to the role index information according to the role index information in the file version submission information.

[0052] In another alternative embodiment provided in the second aspect, the aforementioned apparatus further includes:

[0053] The file viewing request information acquisition unit is used to acquire file viewing request information, which includes a first version identifier, which is the version identifier of the graphical programming file to be viewed.

[0054] The file version submission information acquisition unit is used to obtain the file version submission information of the last saved graphical programming file based on the first version identifier mentioned above.

[0055] The role data acquisition unit is used to acquire the role data of the graphical programming file corresponding to the first version identifier based on the above file version submission information. The role data includes a role storage object and a data storage object.

[0056] The graphical programming file synthesis and display unit is used to synthesize and display the graphical programming file corresponding to the first version identifier in the graphical programming tool based on the above-mentioned role data.

[0057] In another alternative embodiment provided in the second aspect, the aforementioned apparatus further includes:

[0058] The version rollback request information acquisition unit is used to acquire version rollback request information, which includes a second version identifier, which is the version identifier of the graphical programming file for which rollback is requested.

[0059] The differential data determination unit is used to determine the differential data between the graphical programming file corresponding to the second version identifier and the graphical programming file corresponding to the third version identifier according to the differential algorithm. The third version identifier is the version identifier of the last saved graphical programming file.

[0060] The version backtracking unit is used to restore the graphical programming file corresponding to the second version identifier based on the determined differential data, and generate a version backtracking record. The version backtracking record is used to record the backtracking operation of the graphical programming file.

[0061] Thirdly, this application provides a version management device for graphical programming files, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method described in the first aspect or any alternative method of the first aspect.

[0062] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect or any alternative method of the first aspect.

[0063] Fifthly, embodiments of this application provide a computer program product that, when run on a graphical programming file version management device, causes the graphical programming file version management device to execute the steps of the graphical programming file version management method described in the first aspect.

[0064] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0065] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0066] Figure 1 This is a flowchart illustrating a version management method for graphical programming files provided in an embodiment of this application;

[0067] Figure 2 This is a schematic diagram of the data structure of a data storage object provided in an embodiment of this application;

[0068] Figure 3 This is a flowchart illustrating a method for generating a data storage object according to an embodiment of this application;

[0069] Figure 4 This is a schematic diagram of the data structure of a file submission record provided in an embodiment of this application;

[0070] Figure 5 This is a flowchart illustrating a method for updating a version submission list provided in an embodiment of this application;

[0071] Figure 6 This is a flowchart illustrating a graphical programming file viewing method provided in an embodiment of this application;

[0072] Figure 7 This is a flowchart illustrating a graphical programming file backtracking method provided in an embodiment of this application;

[0073] Figure 8 This is a schematic diagram of the structure of a graphical programming file version management device provided in an embodiment of this application;

[0074] Figure 9 This is a schematic diagram of the structure of a graphical programming file version management device provided in an embodiment of this application. Detailed Implementation

[0075] In the following description, specific details such as particular device structures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known devices, systems, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0076] It should be understood that the term "and / or" as used in this application specification and the appended claims refers to any combination of one or more of the associated listed items, as well as all possible combinations, and includes such combinations. Furthermore, in the description of this application specification and the appended claims, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0077] It should also be understood that references to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include the specific features, structures, or characteristics described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0078] Before describing the version management method for graphical programming files provided in the embodiments of this application, the basic concepts of graphical programming involved in the embodiments of this application will be explained.

[0079] Block: The most basic unit of operation in graphical programming. Each role contains several blocks. Blocks are divided into execution blocks, output blocks, conditional blocks, statement blocks, etc., according to their functions. Blocks can be nested to form a new block.

[0080] Target: The basic unit of composition in graphical programming. Each graphical programming file, i.e. the final product of graphical programming, usually contains several targets. Each target is relatively independent and has its own block data. Targets communicate with each other through messages.

[0081] Workspace: The workspace where the currently edited block is located. In graphical programming tools, there is usually only one workspace being edited. Each character corresponds to one workspace. When editing a character, the block data needs to be deserialized into the currently edited workspace, and the block corresponding to the character being edited is rendered in that workspace.

[0082] Graphical programming file: A work file saved in a graphical programming tool. A graphical programming file can also be called a graphical programming work.

[0083] In this embodiment, the graphical programming work is described using a tree structure. This tree structure stores the index addresses of all characters in the graphical programming work, i.e., character index information. When the graphical programming work is saved, a hash value of the tree is generated based on the character index information, resulting in a character index tree with a unique hash value as its index address. When a character is added or deleted in the graphical programming work corresponding to this character index tree, a new character index tree is generated.

[0084] Please see Figure 1 , Figure 1 This is a flowchart illustrating a graphical programming file version management method provided in an embodiment of this application, detailed below:

[0085] Step S101: Obtain the editing information of the above-mentioned graphical programming file, including the creation and / or modification of the character.

[0086] In this embodiment, when a new graphical programming file is created or opened, a block workspace is displayed in the interface of a graphical programming tool such as Scratch. Characters are created or modified within this block workspace. Since each character corresponds to a block workspace, when editing a character—for example, when a user clicks on any character in the character list displayed in the graphical programming tool interface—the blocks contained in that character need to be deserialized and displayed in the current block workspace.

[0087] In the current block workspace, users can create new roles or modify roles in any open version of an existing graphical programming file. For example, they can adjust the position of the role's blocks, add or delete blocks, and adjust the parameters of each block.

[0088] Step S102: Based on the above editing information, generate a character storage object and / or a data storage object.

[0089] In this embodiment, the role storage object records the original data of the newly created role, and the data storage object records the differential data patch generated based on the modification content of the role.

[0090] In this embodiment of the application, when a user creates a new graphical programming file using a graphical programming tool, there are no roles in the graphical programming file. At this time, the user adds roles to the graphical programming file by creating roles. After creating roles, a role storage object is generated. The role storage object is used to store the original data of the role, which is the block data that makes up the role.

[0091] In some embodiments of this application, to facilitate tracking of each role and version management of graphical programming files, an index address is added to each newly created role at the same time, so as to track the changes of roles in different file versions through the index address.

[0092] In some other embodiments of this application, when a user opens a version of a graphical programming file through a graphical programming tool, at least one role exists in the graphical programming file. When the user modifies at least one role in the graphical programming file, after the role is modified, a data storage object is generated based on the differential data patch generated according to the modification content of the role.

[0093] For details, please see Figure 2 and Figure 3 , Figure 2 This is a schematic diagram of the data structure of a data storage object provided in an embodiment of this application. Figure 3 This is a flowchart illustrating a method for generating a data storage object according to an embodiment of this application. Figure 2 For example Figure 3 The steps shown are explained in detail below:

[0094] Step S301: When the above editing information is a modification of the character, the modification content of the character is determined according to the differential algorithm, and a differential data patch is generated.

[0095] In this embodiment of the application, when a user modifies and saves a character in the currently opened version of the graphical programming file in the graphical programming tool, the modified content of the currently edited character is determined according to the diff difference algorithm, and a difference data patch is generated.

[0096] It is understandable that the modifications made to the currently edited character are related to the changes made by the user based on the current version of the character, such as adding or deleting blocks of the character in the current version, and generating differential data patches based on the added or deleted blocks. These differential data patches are equivalent to the incremental data of the current version of the character, and it is not necessary to save the character storage object corresponding to the edited character, which can effectively reduce the version data of the graphical programming file.

[0097] Step S302: Obtain the version identifier information and index address of the modified character. The version identifier information includes the original version identifier and the modified version identifier of the character.

[0098] In this embodiment of the application, in order to quickly and accurately track the relevant content of the modified character, the data storage object that records the differential data patch generated based on the modified content of the character needs to record the version information of the graphical programming file in which the modified character is located, as well as the index address of the modified character.

[0099] Since the modifications made to a character are incremental data generated for the character in the currently edited graphical programming file, any new data storage object added later must depend on the previous data storage object. In other words, any new data storage object added later is based on the previous data storage object, with the addition of generated differential data patches to update the data storage object.

[0100] like Figure 2 As shown, for a data storage object of a character with index address 1, for example, when it has three modified versions, the data storage object stores the original version identifier, the modified version 1 identifier and differential data patch 1 (a differential data patch generated based on the modifications to the character in modified version 1 and the original version), the modified version 2 identifier and differential data patch 2 (a differential data patch generated based on the modifications to the character in modified version 2 and modified version 1), ..., the modified version N identifier and differential data patch N (a differential data patch generated based on the modifications to the character in modified version N and modified version N-1).

[0101] Step S303: Generate the data storage object based on the version identification information, the index address, and the differential data patch.

[0102] In this embodiment of the application, based on the version identifier information, index information, and differential data patch of the modified role, a process is generated as follows: Figure 2 The data storage object shown.

[0103] Step S103: Generate file version submission information based on the aforementioned role storage object and / or the aforementioned data storage object, as well as the role index information.

[0104] In this embodiment of the application, the role index information includes the index address of the role and the address of the role index tree. Through the role index information, all modifications of roles in the graphical programming file can be traced.

[0105] The file version submission information in this embodiment includes a version submission list and a file submission record. The version submission list stores all version information of the graphical programming file, including the original version information and the modified version information. The file submission record records the relevant content of newly created or modified characters. Through the file submission record, the original data of newly created characters and the modified content of modified characters in the corresponding graphical programming file can be queried. Thus, when the modified graphical programming file is opened in the graphical programming tool, the characters can be displayed in reverse sequence in the corresponding block workspace according to the file submission record.

[0106] In this embodiment of the application, the file version submission information can be stored on a local server or through a cloud server. After generating the file version submission information, the file version submission information is sent to the cloud server so that the cloud server can save the file version submission information to the graphical programming file corresponding to the role index information according to the role index information in the file version submission information, so as to facilitate the quick retrieval of the corresponding version of the graphical programming file through the role index tree address.

[0107] In some embodiments of this application, when only one character is created in the graphical programming file, the original data of the character is obtained to generate a character storage object, and an index address is added to the newly created character. Simultaneously, the character index information of the graphical programming file is updated, for example, by adding the index address of the added character to the character index tree address and updating the character index tree address. Based on the character storage object and the updated character index information, a process is generated as follows: Figure 4 The file submission history shown.

[0108] In some other embodiments of this application, when only the original character is modified in the graphical programming file, the modified content of the character is obtained and a data storage object is generated. Based on the data storage object and the character index information corresponding to the character, a file submission record is generated.

[0109] In some other embodiments of this application, when a new role is created in the graphical programming file and an existing role is modified, a role storage object and a data storage object are generated according to the above method, and the role index tree address is updated. Then, a file submission record is generated based on the role storage object, the data storage object, and the role index information.

[0110] In this embodiment, the version submission list is generated when a new graphical programming file is created. When the graphical programming file is modified and saved to be submitted to the cloud server, the version submission list is continuously updated, with each submission's modified version information added to the list. To distinguish between the updated version submission lists, a hash algorithm is used to generate a submission address for the modified version information when it is added to the list. This submission address and the corresponding modified version information are then updated to the list simultaneously. The corresponding version of the graphical programming file can be quickly located using this submission address.

[0111] Please see Figure 5 , Figure 5 This is a flowchart illustrating a method for updating a version commit list according to an embodiment of this application, detailed below:

[0112] Step S501: Obtain the index address of the role in the above data storage object.

[0113] Step S502: Determine the role index tree address of the graphical programming file to which the data storage object belongs based on the index address of the role in the data storage object.

[0114] In this embodiment of the application, each modified role corresponds to a data storage object, which also stores the index address of the role. The index address can be used to determine the role index tree to which the data storage object belongs, thereby determining the version of the graphical programming file in which the role in the data storage object is located.

[0115] Step S503: Based on the above role index tree address, determine the current version information of the graphical programming file to which the above data storage object belongs.

[0116] In this embodiment of the application, each graphical programming file corresponds to a role index tree. When the role in the graphical programming file changes, the version of the graphical programming file also changes accordingly. The version information of the graphical programming file being edited can be determined by the role index tree address of the currently edited graphical programming file.

[0117] Step S504: Based on the current version information mentioned above, determine the version information to be modified.

[0118] In this embodiment of the application, after determining the version information of the graphical programming file currently being edited, the version information of the graphical programming file to be edited, saved and submitted can be determined based on the determined current version information, that is, the modified version information.

[0119] Step S505: Update the above version commit list according to the above modified version information.

[0120] In this embodiment of the application, when adding and updating version modification information to the version commit list, a commit address is generated for the version modification information using a hash algorithm, and the commit address and the corresponding version modification information are updated to the version commit list at the same time. The corresponding version of the graphical programming file can be quickly found through the commit address.

[0121] Please see Figure 6 , Figure 6 This is a flowchart illustrating a graphical programming file viewing method provided in an embodiment of this application, detailed below:

[0122] Step S601: Obtain file viewing request information. The file viewing request information includes a first version identifier, which is the version identifier of the graphical programming file to be viewed.

[0123] In this embodiment of the application, when a user clicks on the version list of graphical programming files on a local server or cloud server, a file viewing request is generated. This file viewing request includes the version identifier of the graphical programming file selected by the user, so that the corresponding graphical programming work can be displayed on the graphical programming tool according to the version identifier.

[0124] Step S602: Based on the first version identifier mentioned above, obtain the last saved file version submission information of the graphical programming file.

[0125] Step S603: Based on the above file version submission information, obtain the role data of the graphical programming file corresponding to the first version identifier. The role data includes role storage objects and data storage objects.

[0126] In this embodiment of the application, the last saved file version submission information of the graphical programming file is obtained based on the version identifier of the graphical programming file, so as to obtain the role data of the graphical programming file from the file version submission information, thereby determining the index address of the role and the modified content of the role based on the role storage object and the data storage object.

[0127] Step S604: Based on the above role data, synthesize and display the graphical programming file corresponding to the first version identifier in the graphical programming tool.

[0128] In this embodiment of the application, after obtaining the character storage object and the data storage object, the corresponding graphical programming work is synthesized and displayed in the graphical programming tool based on the character's original data and modified content through deserialization.

[0129] In some embodiments of this application, users need to backtrack their graphical programming work to a certain historical version, such as version 1. In order to ensure the integrity of the file submission records after version 1, a version backtracking record needs to be generated to record the difference data between the backtracked version and the latest version of the graphical programming work, so as to ensure the integrity of the version information in the version submission chain after the backtracking operation, and to prevent the loss of version information after version 1.

[0130] Please see Figure 7 , Figure 7 This is a flowchart illustrating a graphical programming file backtracking method provided in an embodiment of this application, detailed below:

[0131] Step S701: Obtain version rollback request information. The version rollback request information includes a second version identifier, which is the version identifier of the graphical programming file for which rollback is requested.

[0132] Step S702: Based on the differential algorithm, determine the differential data between the graphical programming file corresponding to the second version identifier and the graphical programming file corresponding to the third version identifier, wherein the third version identifier is the version identifier of the last saved graphical programming file.

[0133] Step S703: Based on the determined differential data, restore the graphical programming file corresponding to the second version identifier and generate a version backtracking record. The version backtracking record is used to record the backtracking operation of the graphical programming file.

[0134] In this embodiment, by acquiring the editing information of the graphical programming file, and generating a data storage object that records the original data role of the newly created role and / or the differential data patch generated based on the modification content of the role, and then generating file version submission information based on the role storage object, the data storage object, and the role index information of the graphical programming file, it is not necessary to save the entire graphical programming file. Instead, only the file version submission information generated based on the role storage object generated based on the newly created role and / or the data storage object generated based on the modified role, and the role index information of the graphical programming file is saved. This greatly reduces the version data of the graphical programming file that needs to be saved. By recording the changes of the role through incremental data storage objects, the modification of the role in the graphical programming file can be tracked quickly and effectively, improving the tracking efficiency and accuracy of the graphical programming file and providing a better user experience.

[0135] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0136] Based on the version management method for graphical programming files provided in the above embodiments, this application further provides an apparatus embodiment for implementing the above method embodiments.

[0137] Please see Figure 8 , Figure 8 This is a schematic diagram of a graphical programming file version management device provided in an embodiment of this application. The included units are used for execution... Figure 1 The steps in the corresponding embodiments. Please refer to the details. Figure 1 The relevant descriptions in the corresponding embodiments are shown below. For ease of explanation, only the parts relevant to this embodiment are shown. See also... Figure 8 The graphical programming file version management device 8 includes:

[0138] The editing information acquisition unit 81 is used to acquire the editing information of the above-mentioned graphical programming file, including the creation and / or modification of the character;

[0139] The storage object generation unit 82 is used to generate a character storage object and / or a data storage object based on the above editing information. The character storage object records the original data of the newly created character, and the data storage object records differential data patches generated based on the modifications made to the character.

[0140] The file version submission information generation unit 83 is used to generate file version submission information based on the aforementioned role storage object and / or the aforementioned data storage object, as well as role index information, wherein the aforementioned role index information includes the index address of the role.

[0141] In some embodiments of this application, the storage object generation unit 82 described above is used for:

[0142] When the above editing information involves modifications to a character, the modified content of the character is determined according to the differential algorithm, and a differential data patch is generated.

[0143] Obtain the version identifier information and index address of the modified character. The version identifier information includes the original version identifier and the modified version identifier of the character.

[0144] Based on the version identification information, the index address, and the differential data patch, the data storage object is generated.

[0145] In other embodiments of this application, the above-mentioned file version submission information includes a version data linked list, and the above-mentioned file version submission information generation unit 83 is used for:

[0146] Obtain the index address of the role in the above data storage object;

[0147] Based on the index address of the role in the above data storage object, determine the role index tree address of the graphical programming file to which the above data storage object belongs;

[0148] Based on the above role index tree address, determine the current version information of the graphical programming file to which the above data storage object belongs;

[0149] Based on the current version information above, determine the version information to be modified;

[0150] Update the commit list of the above versions based on the modified version information.

[0151] In other embodiments of this application, the above-mentioned file version submission information includes file submission records, and the above-mentioned file version submission information generation unit 83 is further used for:

[0152] Based on the aforementioned role storage object and role index information, generate a file commit record; or:

[0153] Based on the aforementioned data storage objects and role index information, generate a file commit record; or:

[0154] Based on the aforementioned role storage object, the aforementioned data storage object, and the aforementioned role index information, a file commit record is generated.

[0155] In other embodiments of this application, the above-described apparatus further includes:

[0156] The file version submission information sending unit is used to send the file version submission information to the cloud server. The cloud server saves the file version submission information to the graphical programming file corresponding to the role index information according to the role index information in the file version submission information.

[0157] In other embodiments of this application, the above-described apparatus further includes:

[0158] The file viewing request information acquisition unit is used to acquire file viewing request information, which includes a first version identifier, which is the version identifier of the graphical programming file to be viewed.

[0159] The file version submission information acquisition unit is used to obtain the file version submission information of the last saved graphical programming file based on the first version identifier mentioned above.

[0160] The role data acquisition unit is used to acquire the role data of the graphical programming file corresponding to the first version identifier based on the above file version submission information. The role data includes a role storage object and a data storage object.

[0161] The graphical programming file synthesis and display unit is used to synthesize and display the graphical programming file corresponding to the first version identifier in the graphical programming tool based on the above-mentioned role data.

[0162] In other embodiments of this application, the above-described apparatus further includes:

[0163] The version rollback request information acquisition unit is used to acquire version rollback request information, which includes a second version identifier, which is the version identifier of the graphical programming file for which rollback is requested.

[0164] The differential data determination unit is used to determine the differential data between the graphical programming file corresponding to the second version identifier and the graphical programming file corresponding to the third version identifier according to the differential algorithm. The third version identifier is the version identifier of the last saved graphical programming file.

[0165] The version backtracking unit is used to restore the graphical programming file corresponding to the second version identifier based on the determined differential data, and generate a version backtracking record. The version backtracking record is used to record the backtracking operation of the graphical programming file.

[0166] In this embodiment, by acquiring the editing information of the graphical programming file, and generating a data storage object that records the original data role of the newly created role and / or the differential data patch generated based on the modification content of the role, and then generating file version submission information based on the role storage object, the data storage object, and the role index information of the graphical programming file, it is not necessary to save the entire graphical programming file. Instead, only the file version submission information generated based on the role storage object generated based on the newly created role and / or the data storage object generated based on the modified role, and the role index information of the graphical programming file is saved. This greatly reduces the version data of the graphical programming file that needs to be saved. By recording the changes of the role through incremental data storage objects, the modification of the role in the graphical programming file can be tracked quickly and effectively, improving the tracking efficiency and accuracy of the graphical programming file and providing a better user experience.

[0167] It should be noted that the information interaction and execution process between the above modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0168] Figure 9 This is a schematic diagram of a graphical programming file version management device provided in an embodiment of this application. For example... Figure 9As shown, the graphical programming file version management device 9 of this embodiment includes: a processor 90, a memory 91, and a computer program 92 stored in the memory 91 and executable on the processor 90, such as a version management program. When the processor 90 executes the computer program 92, it implements the steps in the various graphical programming file version management method embodiments described above, for example... Figure 1 Steps 101-103 are shown. Alternatively, when processor 90 executes computer program 92, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 8 The functions of units 81-83 shown.

[0169] For example, computer program 92 can be divided into one or more modules / units, one or more of which are stored in memory 91 and executed by processor 90 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of computer program 92 in graphical programming file version management device 9. For example, computer program 92 can be divided into an editing information acquisition unit 81, a storage object generation unit 82, and a file version submission information generation unit 83. For the specific functions of each unit, please refer to [link to relevant documentation]. Figure 1 The relevant descriptions in the corresponding embodiments are not repeated here.

[0170] The version management device for graphical programming files may include, but is not limited to, processor 90 and memory 91. Those skilled in the art will understand that... Figure 9 This is merely an example of a graphical programming file version management device 9 and does not constitute a limitation on the graphical programming file version management device 9. It may include more or fewer components than illustrated, or combine certain components, or different components. For example, a graphical programming file version management device may also include input / output devices, network access devices, buses, etc.

[0171] The processor 90 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0172] The memory 91 can be an internal storage unit of the graphical programming file version management device 9, such as a hard disk or memory of the graphical programming file version management device 9. The memory 91 can also be an external storage device of the graphical programming file version management device 9, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the graphical programming file version management device 9. Furthermore, the memory 91 can include both internal storage units and external storage devices of the graphical programming file version management device 9. The memory 91 is used to store computer programs and other programs and data required by the graphical programming file version management device. The memory 91 can also be used to temporarily store data that has been output or will be output.

[0173] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the above-described version management method for graphical programming files.

[0174] This application provides a computer program product that, when run on a graphical programming file version management device, enables the graphical programming file version management device to implement the aforementioned graphical programming file version management method.

[0175] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0176] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0177] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0178] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for version management of graphical programming files, characterized in that, The method includes: Obtain the editing information of the graphical programming file, including the creation and / or modification of characters; Based on the editing information, a character storage object and / or a data storage object are generated. The character storage object records the original data of the newly created character, and the data storage object records differential data patches generated based on the character's modifications. Based on the role storage object and / or the data storage object, and the role index information, generate file version submission information, wherein the role index information includes the index address of the role; The file version submission information is sent to the cloud server, and the cloud server saves the file version submission information to the graphical programming file corresponding to the role index information according to the role index information. The step of generating a character storage object and / or a data storage object based on the edit information includes: when the edit information is a modification of a character, determining the modified content of the character according to a differential algorithm and generating a differential data patch; obtaining the version identifier information and index address of the modified character, wherein the version identifier information includes the original version identifier and the modified version identifier of the character; and generating the data storage object based on the version identifier information, the index address, and the differential data patch. The file version submission information includes a version submission linked list. Generating file version submission information based on the role storage object and / or the data storage object, and role index information, includes: obtaining the index address of the role in the data storage object; determining the role index tree address of the graphical programming file to which the data storage object belongs based on the index address of the role in the data storage object; determining the current version information of the graphical programming file to which the data storage object belongs based on the role index tree address; determining the modified version information based on the current version information; and updating the version submission linked list based on the modified version information.

2. The version management method for graphical programming files as described in claim 1, characterized in that, The file version submission information includes file submission records. The process of generating file version submission information based on the role storage object and / or the data storage object, and the role index information, further includes: Generate a file submission record based on the role storage object and the role index information; or: Generate a file submission record based on the data storage object and the role index information; or: A file submission record is generated based on the role storage object, the data storage object, and the role index information.

3. The version management method for graphical programming files as described in claim 1, characterized in that, After generating the file version submission information based on the role storage object and / or the data storage object, and the role index information, the method further includes: Obtain file viewing request information, which includes a first version identifier, which is the version identifier of the graphical programming file to be viewed; Based on the first version identifier, obtain the last saved file version submission information of the graphical programming file; Based on the file version submission information, obtain the role data of the graphical programming file corresponding to the first version identifier. The role data includes a role storage object and a data storage object. Based on the character data, a graphical programming file corresponding to the first version identifier is synthesized and displayed in a graphical programming tool.

4. The version management method for graphical programming files as described in claim 1, characterized in that, After generating the file version submission information based on the role storage object and / or the data storage object, and the role index information, the method further includes: Obtain version rollback request information, which includes a second version identifier, which is the version identifier of the graphical programming file for which rollback is requested; Based on the differential algorithm, the differential data of the graphical programming file corresponding to the second version identifier and the graphical programming file corresponding to the third version identifier are determined, wherein the third version identifier is the version identifier of the last saved graphical programming file. Based on the determined differential data, the graphical programming file corresponding to the second version identifier is restored, and a version backtracking record is generated. The version backtracking record is used to record the backtracking operation of the graphical programming file.

5. A graphical programming file version management device, characterized in that, The device includes: An editing information acquisition unit is used to acquire editing information of the graphical programming file, the editing information including the creation and / or modification of characters; The storage object generation unit is used to generate a character storage object and / or a data storage object based on the editing information. The character storage object records the original data of the newly created character, and the data storage object records differential data patches generated based on the modifications made to the character. The file version submission information generation unit is used to generate file version submission information based on the role storage object and / or the data storage object, as well as the role index information, wherein the role index information includes the index address of the role. The file version submission information sending unit is used to send the file version submission information to the cloud server. The cloud server saves the file version submission information to the graphical programming file corresponding to the role index information according to the role index information in the file version submission information. The storage object generation unit is specifically used for: when the editing information is a modification of a character, determining the modified content of the character according to a differential algorithm and generating a differential data patch; obtaining the version identifier information and index address of the modified character, wherein the version identifier information includes the original version identifier and the modified version identifier of the character; and generating the data storage object according to the version identifier information, the index address and the differential data patch. The file version submission information includes a version submission linked list. The file version submission information generation unit is specifically used for: obtaining the index address of the role in the data storage object; determining the role index tree address of the graphical programming file to which the data storage object belongs based on the index address of the role in the data storage object; determining the current version information of the graphical programming file to which the data storage object belongs based on the role index tree address; determining the modified version information based on the current version information; and updating the version submission linked list based on the modified version information.

6. A graphical programming file version management device, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the version management method for graphical programming files as described in any one of claims 1 to 4.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the version management method for graphical programming files as described in any one of claims 1 to 4.

Images