Version management method
By checking version reference information and establishing version parent-child relationships, the problem of low efficiency in concurrent operations in version management is solved, enabling rapid updates and efficient storage management, thus improving the overall efficiency of version management.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HUNAN UNIV
- Filing Date
- 2023-04-18
- Publication Date
- 2026-07-03
AI Technical Summary
Existing version control technologies are inefficient under concurrent operations. In LMU mode, users wait a long time, and in CMM mode, repeated modifications may be required, resulting in reduced management efficiency.
By checking the version reference information of the managed object, it is determined whether there is a user reference. The copy is then directly updated or copied as a child version. A parent-child relationship between versions is established, and the process of locking version modification, version copying, and version re-signing is adopted. Update and deletion operations are performed in conjunction with the version relationship diagram.
It enables rapid updates during low-concurrency operations, improves efficiency during high-concurrency operations, avoids redundant modifications, enhances the overall efficiency of version management, and optimizes storage resource utilization through version switching and recycle bin mechanisms.
Smart Images
Figure CN116594669B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer technology, and in particular relates to a version management method. Background Technology
[0002] A version is a snapshot recording the various states of a specific object. Version management's task is to record and maintain the historical evolution of an object, selecting the appropriate version based on the actual application scenario. Version management mainly includes functions such as version generation, version update, version deletion, and rollback. Furthermore, it needs to be able to uniformly coordinate and manage various versions, effectively record the evolution process of different versions, and effectively manage different versions with minimal data redundancy. At the same time, it must ensure logical consistency and relative independence between different versions; users must use versions consistent with the specified versions, and the creation and disappearance of one version should not affect other versions.
[0003] Currently, version control technologies mainly employ two modes: Lock-Modify-Unlock (LMU) and Copy-Modify-Merge (CMM). In LMU mode, locking effectively prevents conflicts caused by multiple users modifying a file simultaneously. However, it reduces the number of concurrent user operations, and if a user forgets to unlock after making changes, subsequent users wanting to modify the same version will be waiting for unlocking, resulting in low management efficiency. In CMM mode, when a user modifies a file, they can first update the server file to their local machine, then modify the copy locally, and finally commit the copy to the server. If the original file has already been modified and committed by another user before this user's commit, the version number on the server will differ from the local version number, causing the server to abort the commit. The user must then obtain the new version and modify and commit again. While CMM mode has a shorter waiting time than LMU and can increase operational concurrency, it may require repeated modification operations, again reducing management efficiency. Summary of the Invention
[0004] Therefore, it is necessary to provide a version management method that can improve management efficiency to address the aforementioned technical issues.
[0005] This invention provides a version management method, comprising:
[0006] Check the version reference information of the managed object version according to the update instruction of the managed object version;
[0007] Determine whether the version of the managed object currently has a user reference based on the version reference information;
[0008] When there are no user references, the version of the managed object is updated directly;
[0009] When a user references the managed object, a copy of the managed object version is copied and fed back to the user for update, and the copy is established as a child version of the managed object version to establish a version parent-child relationship.
[0010] In one embodiment, updating the managed object version directly when there is no user reference includes:
[0011] When there are no user references, lock the version of the managed object and copy it to the user for modification. Obtain the modified copy and check the user reference status of the managed object version a second time.
[0012] If the second check determines that there is no user reference, the copy will be replaced with the version of the managed object;
[0013] If a secondary check confirms the existence of a user reference, the copy is established as a sub-version of the managed object version, creating a version parent-child relationship.
[0014] In one embodiment, the method further includes:
[0015] Display the working version of the managed object according to the user's instruction to retrieve the managed object;
[0016] If a user's version switching command is received, a version relationship diagram will be displayed to the user.
[0017] Switch the working version to the management object version selected by the user according to the version relationship diagram and update the corresponding version reference information.
[0018] In one embodiment, the method further includes:
[0019] Based on the deletion command for the managed object version, determine whether the managed object version is a working version and check the reference information of the managed object version;
[0020] When the version of the managed object is the working version, the deletion operation is rejected and a prompt is made to switch versions.
[0021] When the version of the managed object is not the default working version, the corresponding deletion operation is performed on the managed object version according to the reference information of the managed object version.
[0022] In one embodiment, performing a corresponding deletion operation on the managed object version based on the reference information of the managed object version includes:
[0023] When a version of the managed object is referenced by a user, the offline version of the managed object is moved to the version recycle bin.
[0024] When the managed object version is no longer referenced by any user, the managed object version is taken offline and moved to the version recycle bin, and then the managed object version is completely deleted from the version recycle bin.
[0025] In one embodiment, the version relationship graph is synchronously invoked to update the version relationship when establishing the version parent-child relationship.
[0026] In one embodiment, the version relationship graph is presented in a tree structure.
[0027] The aforementioned version management method checks the version reference information of the managed object version through update commands. Based on this information, it determines whether a user currently references the managed object version. If no user reference exists, the managed object version is updated directly. If a user reference exists, a copy of the managed object version is created and sent to the user for update, establishing a parent-child relationship between the copy and the managed object version. This method selects an appropriate update method based on the recorded version reference information. It can quickly complete version updates under low concurrency, and even under high concurrency, the use of sub-versions improves update efficiency, thereby enhancing version management efficiency. Attached Figure Description
[0028] Figure 1 This is a flowchart illustrating a version management method in one embodiment.
[0029] Figure 2 This is a flowchart illustrating a version update method in one embodiment.
[0030] Figure 3 This is a schematic diagram of the version relationship diagram in one embodiment.
[0031] Figure 4 This is a flowchart illustrating a version deletion method in one embodiment. Detailed Implementation
[0032] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.
[0033] In one embodiment, such as Figure 1 As shown, a version management method is provided, including the following steps:
[0034] Step S101: Check the version reference information of the managed object version according to the update instruction of the managed object version. Step S102: Determine whether a user currently references the managed object version based on the version reference information.
[0035] Step S103: When there is no user reference, directly update the version of the managed object.
[0036] Step S104: When there is a user reference, copy the version of the managed object and send it back to the user for update, and establish a version parent-child relationship as a child version of the managed object version.
[0037] In this context, a managed object refers to the object being managed, and a managed object version refers to the version of the managed object. A managed object can have multiple versions created sequentially, but each managed object has exactly one version in use, which is called the working version. In other words, a managed object can have many versions, with the one currently in use being called the working version. The working version can default to the latest version or be specified according to actual needs. Each version of a managed object has corresponding version reference information, recording the service status of the managed object version, including version usage, association information, and reference information. When a managed object version is accessed and used by a user, its corresponding reference information should be updated synchronously.
[0038] Specifically, when a user needs to update a version of a managed object and the server receives the update command, it first checks the version reference status of that managed object. This is determined by retrieving the corresponding version reference information. If the version to be updated has existing user references, it is checked off, a new copy is created for the user to modify, and the modified copy becomes a child version of the original managed object, establishing a parent-child relationship. Simultaneously, the child version's version reference information is initialized, and the version relationship is updated in the version graph. If the version to be updated has no existing user references, the updated managed object is directly modified, and the version number remains unchanged after the update.
[0039] In one embodiment, step S103 includes: when there is no user reference, locking the management object version and copying a copy to provide feedback to the user for modification, obtaining the modified copy and performing a second check on the user reference status of the management object version; if the second check determines that there is no user reference, replacing the copy with the management object version; if the second check determines that there is a user reference, establishing a version parent-child relationship between the copy and the management object version.
[0040] Specifically, this embodiment employs a version update process involving locking version modification, version copying, and version re-signing. During the version update process, the version service before the update is not interrupted. During version re-signing, the user reference status of the updated managed object version is checked again. If the second check confirms the existence of user references, the process proceeds to generate a new version. This involves establishing a parent-child relationship between the copy and the managed object version, initializing the version reference information of the child version, and updating the version relationship in the version relationship graph. Otherwise, the content data of the updated managed object version is directly updated; that is, the modified copy is re-signed back to the updated managed object version, replacing the original version content with the modified content. Furthermore, when establishing the parent-child relationship, the version relationship graph is synchronously updated to reflect the version relationships of the managed object. For example, when adding a child version, a new child node is added to the version relationship graph.
[0041] For details of the version management method process described in the above embodiments, please refer to [link / reference]. Figure 2 The flowchart shown illustrates the version update method. This method selects an appropriate update approach based on the recorded version references. It can quickly complete version updates under low concurrency, while also improving update efficiency through sub-versioning under high concurrency, thus enhancing version management efficiency. Furthermore, the version update reference checking mechanism ensures that users can trace the specific content of the corresponding version of the managed object at any time based on the version usage history.
[0042] In one embodiment, the version management method further includes a version switching method, comprising: displaying the working version of the managed object according to the user's instruction to retrieve the managed object; if a version switching instruction is received from the user, displaying a version relationship diagram to the user; switching the working version to the version of the managed object selected by the user according to the version relationship diagram and updating the corresponding version reference information.
[0043] Specifically, when a user needs to access and use a managed object, the server first responds with the working version of the managed object. That is, after the user selects a managed object, the system returns the content of that working version to the user by default and updates the corresponding version reference information. Then, the user can further switch the working version of the managed object according to their needs. During version switching, the user clicks a "send version switch" command to instruct the server to list all version information of the managed object and present a version relationship diagram. Then, the user clicks the "send version" command again to select the version to switch to. The server switches the working version to the managed object version selected by the user according to the version relationship diagram and updates the version reference information corresponding to the selected version, thus completing the working version switch. The version to be switched to can be selected by the user according to the scenario requirements and reference relationships. After the working version switch, the object obtained by the user again will be the content corresponding to the switched version. In this embodiment, the user can flexibly and freely choose to switch to all versions of the managed object. There is no version rollback operation during version switching, which can be completed quickly in a short time without increasing the number of versions or incurring any storage or performance overhead.
[0044] In this embodiment, the version relationship diagram is preferably presented in a tree structure. This tree-structured version relationship allows for full lifecycle version management of managed objects, recording the version history evolution of the managed objects and presenting the relationships between versions. The visual display of version relationships intuitively demonstrates version differences, providing users with a reference and service for selecting the most suitable version. The version relationships of managed objects are mainly divided into three types: parent-child, sibling, and grandparent-grandchild. Here, version relationships refer to the relationships between multiple versions of the same managed object; different managed objects do not have version relationships. Parent-child relationships are further divided into the following cases: when creating a new version, the new version is a child version of the original version, and the relationship between the new version and the original version is a parent-child relationship. Two versions with the same parent version constitute a sibling relationship, and two or more levels of parent-child relationships constitute a grandparent-grandchild relationship. In other words, the version relationship of the managed objects can be represented by an inverted tree. Each version corresponds to a node in the tree, with the parent node representing the parent version and the child node representing the child version. Two parent-child nodes correspond to a parent-child relationship, and sibling nodes correspond to a sibling relationship. In this embodiment, such a version relationship tree is called a version tree. The root node (without a parent node) is the earliest version, and the leaf nodes (without children nodes) are the latest version. The version relationship graph accurately records the process of version changes of the managed objects. Version relationships cannot be modified or deleted, and deleting a version does not affect the management of the version relationships of the managed objects.
[0045] In this embodiment, version switching replaces version rollback, offering flexibility and freedom in version switching. It avoids the issues of version rollback creating new version information and the new version copying the rolled-back content. Therefore, version switching improves version management efficiency, increases storage resource utilization, and avoids wasted storage space. Users can choose to switch versions according to their needs, and can use the object version's scenario, description, and other relevant attributes and version references as references for version selection. Furthermore, it provides full lifecycle version relationship management for managed objects, and the version relationships of managed objects can be displayed graphically. (See...) Figure 3 The version relationship diagram shown allows for tracing the history of any version through version management.
[0046] In one embodiment, the version management method further includes a version deletion method, comprising: determining whether the managed object version is a working version based on the deletion instruction of the managed object version and checking the reference information of the managed object version; when the managed object version is a working version, rejecting the deletion operation and prompting for version switching; when the managed object version is not the default working version, performing the corresponding deletion operation on the managed object version based on the reference information of the managed object version.
[0047] In one embodiment, the corresponding deletion operation is performed on the managed object version based on the reference information of the managed object version, including: when the managed object version has user references, the offline managed object version is moved to the version recycle bin; when the managed object version has no user references, after the offline managed object version is moved to the version recycle bin, the managed object version is completely deleted from the version recycle bin.
[0048] For details, please refer to Figure 4The version deletion flowchart shown illustrates that when a user needs to delete a managed object version, the server first needs to determine whether the version to be deleted is a working version and its reference status. If the version to be deleted is currently a working version, direct deletion is not allowed; a version switch is required to change the version of the target managed object to a non-working version before the deletion operation can be performed. If the version to be deleted is a non-working version, the deletion operation can be performed, but it is not completely erased; instead, it is taken offline and enters the version recycle bin. This means the deleted version is soft-deleted, not physically deleted, and users cannot use it as a working version after a soft deletion. In other words, versions in the version recycle bin are version data that have not been actually deleted. In this embodiment, the version recycle bin has three functions: First, it allows the recovery of deleted versions, which can continue to provide services to users. Second, it allows users to track and find specific version content based on usage records, achieving full lifecycle tracking management of versions. Third, it completely deletes versions without reference status; the system will clear the data content, while versions with reference status cannot be cleared. That is, when a managed object version is taken offline and moved to the version recycle bin, its reference status can be used to determine whether to completely delete it. If there is no reference, it can be completely deleted, while if there is a reference, it cannot be deleted.
[0049] In this embodiment, the version soft deletion recycle bin mechanism can ensure that users can trace the specific content of the corresponding version of the managed object at any time according to the version usage record, and the version recycle bin can restore the deleted version, effectively avoiding the problem of version loss.
[0050] In addition, the version management data stored in the database of this invention mainly includes version management information and version relationship information. To better manage version data, considering general database design principles and the data frequency of the version management system, this invention employs a forward-looking database design. MySQL is preferred, and the database model adopts a master-slave high-availability architecture to meet high availability and high-performance requirements. The specific database table structure is shown in the following tables, including a version relationship table (Table 1), a management object information table (Table 2), and a version information table (Table 3).
[0051] Table 1 Version Relationship Table
[0052] name Label Content type Required only illustrate serial number code varchar(12) yes yes Self-incrementing Management object number objectId varchar(10) yes no Version number version varchar(12) yes yes Version Name name varchar(20) yes no Parent ID pcode int(4) yes yes
[0053] Table 2 Information on Management Objects
[0054] name Label Content type Required only illustrate serial number rule_id int(4) yes yes Self-incrementing Management object name rule_name varchar(15) yes yes working version number rule_work_id int(4) yes yes fingerprint rule_md5 int(4) yes no describe rule_bz varchar(100) yes no
[0055] Table 3 Version Information Table
[0056] name Label Content type Required only illustrate Version number version_id int(4) yes yes Self-incrementing Version Name version_name varchar(15) yes no Version Notes version_desc varchar(10) yes no Object Number version_no int(4) yes no Delete mark version_deleted int(4) yes no Scene version_scene varchar(10) yes no Creation time create_time Date yes no Modified time update_time Date yes no describe version_desc varchar(20) no no
[0057] It should be understood that, although Figure 1 , 2 The steps in flowchart 4 are shown sequentially as indicated by the arrows; however, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are performed, and they can be executed in other orders. Figure 1 , 2 At least some of the steps in 4 may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.
[0058] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0059] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.
Claims
1. A version management method characterized by, include: Check the version reference information of the managed object version according to the update instruction of the managed object version; Determine whether the version of the managed object currently has a user reference based on the version reference information; When there are no user references, the version of the managed object is updated directly; When a user reference exists, a copy of the managed object version is copied and fed back to the user for update, and the copy is established as a child version of the managed object version to establish a version parent-child relationship; When there are no user references, the version of the managed object is directly updated, and the version number of the managed object remains unchanged after the update, including: When there are no user references, lock the version of the managed object and copy it to the user for modification. Obtain the modified copy and check the user reference status of the managed object version a second time. If the second check determines that there is no user reference, the copy will be replaced with the version of the managed object; If a secondary check confirms the existence of a user reference, the copy is established as a sub-version of the managed object version, creating a version parent-child relationship.
2. The method of claim 1, wherein, The method further includes: Display the working version of the managed object according to the user's instruction to retrieve the managed object; If a user's version switching command is received, a version relationship diagram will be displayed to the user. Switch the working version to the management object version selected by the user according to the version relationship diagram and update the corresponding version reference information.
3. The method of claim 1, wherein, The method further includes: Based on the deletion command for the managed object version, determine whether the managed object version is a working version and check the reference information of the managed object version; When the version of the managed object is the working version, the deletion operation is rejected and a prompt is made to switch versions. When the version of the managed object is not the default working version, the corresponding deletion operation is performed on the managed object version according to the reference information of the managed object version.
4. The method according to claim 3, characterized in that, The step of performing a corresponding deletion operation on the managed object version based on the reference information of the managed object version includes: When a version of the managed object is referenced by a user, the managed object version is taken offline and moved to the version recycle bin; When the managed object version is no longer referenced by any user, the managed object version is taken offline and moved to the version recycle bin, and then the managed object version is completely deleted from the version recycle bin.
5. The method according to claim 1, characterized in that, When establishing version parent-child relationships, the version relationship graph is called synchronously to update the version relationships.
6. The method according to claim 2, characterized in that, The version relationship diagram is presented in a tree structure.