Version management control method and system

Abstract

Embodiments of the present application relate to the technical field of version management, and disclose a version management control method and system. The method is applied to a client and comprises the following steps: in response to receiving a version submission instruction, extracting a difference storage object from a local object storage and generating a difference description file of version metadata based on a comparison result of a master version tree and a slave version tree of the client; wherein the difference storage object represents incremental change data of file content, and the difference description file is used to represent structural differences between the master version tree and the slave version tree; sending the difference storage object to a cache area of a central server through a first transmission link; and sending the difference description file to a pre-configured receiving end through a second transmission link. The technical solution of the present application can retain the advantages of enterprise-level centralized governance, integrate the availability and flexibility of a distributed architecture, and provide native support for safe, efficient and reliable version collaboration in a DevOps scenario.

Description

Technical Field

[0001] This invention relates to the field of version management technology, specifically to a version management control method and system. Background Technology

[0002] As enterprises gradually shift their R&D models from traditional waterfall development to DevOps (Development + Operations) integration, version control systems are no longer just code management tools, but have become a key collaborative infrastructure connecting development and operations teams, providing version consistency guarantees for continuous integration, continuous delivery, and automated deployment.

[0003] Currently, mainstream version control systems are mainly divided into two categories: centralized version control systems and distributed version control systems. In enterprise-level DevOps practices, both architectures have significant drawbacks, as detailed below.

[0004] While centralized systems offer a "single trusted source," facilitating unified management and auditing, their version interactions rely on complete objects (such as file snapshots), making lightweight communication difficult. More importantly, all version data is centrally stored on a central server, with clients holding only working copies rather than the complete repository. If the central server crashes or data becomes corrupted, developers will be unable to submit changes, view history, or collaborate locally, disrupting the entire development process and severely limiting system availability.

[0005] While distributed systems provide each client with a complete version history and offline operation capabilities, enhancing development flexibility, the lack of a mandatory centralized node inherently creates a "single source of trust," posing challenges to enterprise compliance management, security auditing, and release control. Even if teams logically establish a central repository as the merge entry point through process agreements (such as GitHub Flow), in practice, issues such as members failing to synchronize remote status in a timely manner, inconsistent branching strategies, or communication delays often lead to a proliferation of local branches on clients, frequent merge conflicts, and high costs for conflict resolution, severely impacting delivery efficiency and system stability. Summary of the Invention

[0006] In view of the shortcomings of the prior art, the purpose of this application is to provide a version management control method and system that aims to retain the advantages of enterprise-level centralized governance while integrating the availability and flexibility of distributed architecture, and to provide native support for secure, efficient and reliable version collaboration in DevOps scenarios.

[0007] In a first aspect, embodiments of this application provide a version management control method, which is applied to a client and includes: In response to receiving a version commit instruction, based on the comparison results between the client's main version tree and the secondary version tree, a difference storage object is extracted from the local object storage, and a difference description file of version metadata is generated; wherein, the difference storage object represents the incremental change data of the file content, and the difference description file is used to represent the structural differences between the main version tree and the secondary version tree; The differential storage object is sent to the cache of the central server via the first transmission link; The difference description file is sent to a pre-configured receiving end via a second transmission link.

[0008] In the above technical solution, after receiving the version commit instruction, the client extracts a difference storage object representing incremental changes in file content based solely on the comparison results between the main version tree and the secondary version tree, and generates a difference description file describing the structural differences. The difference storage object and the difference description file are independently sent to the central server's cache and a pre-configured receiving end via a first transmission link and a second transmission link, respectively. This mechanism avoids uploading complete files or large snapshots, significantly reducing network bandwidth consumption and commit latency, making it particularly suitable for weak network environments or large-scale codebase scenarios, and helping to improve the developer's commit experience and system response speed. Furthermore, since the client's main version tree is configured to continuously track the version status of the central server, it ensures that the view of enterprise digital assets on the client side is consistent with the central server, which is beneficial for integrity maintenance and audit traceability. Meanwhile, the secondary version tree allows developers to commit versions offline locally. Based on this, when the central server temporarily fails, the system can dynamically designate a client copy aligned with the central server's state as a temporary trusted source, thereby avoiding development process interruptions. Thus, while retaining the advantages of centralized governance with a "single trusted source," it effectively improves the availability and resilience of the development process.

[0009] In one embodiment, the method further includes: in response to receiving a version update instruction, obtaining update information pushed by the central server through a second transmission link, and applying the update information to the client's main version tree to achieve version tree synchronization; wherein, the version tree synchronization only updates the structural information of the version tree and does not trigger the automatic transmission of the storage object; when an access request for the target storage object is detected, in response to a pull instruction triggered by the user, pulling the target storage object from the central server through the first transmission link.

[0010] In the above technical solution, the client responds to the version update command by obtaining the update information pushed by the central server only through the second transmission link and applying it to the main version tree to complete the structure synchronization. This process only involves the metadata of the version tree and does not transmit any storage objects, thereby significantly reducing network bandwidth consumption and synchronization latency. This allows developers to quickly perceive the latest status of the central repository, which is especially suitable for high-frequency collaboration or large-scale team scenarios. After the main version tree synchronization is completed, the client only holds the complete version structure index locally, while the underlying storage objects remain on the central server. When a user actually accesses a specific file and triggers a pull command, the system downloads the corresponding target storage object from the central server through the first transmission link. This mechanism effectively avoids redundant downloads of all objects and significantly saves local storage space and network resources.

[0011] In one embodiment, when a client is designated as a temporary central server, the method further includes: broadcasting a switchover notification message to other clients so that the other clients associate the synchronization source with this client; and pushing the version data generated during the switchover to the restored central server when the original central server is detected to be restored.

[0012] In the above technical solution, by promoting clients with complete and aligned states to temporary central servers, they can continue to receive version commits and broadcast change notifications from other clients, thereby maintaining team collaboration continuity and significantly improving system resilience. When the original central server returns to online, the temporary central server proactively pushes all version data received and managed during the switchback back to the original central server. The central server then updates its version tree and object storage accordingly and broadcasts a recovery notification, guiding all clients to re-associate with the central server. This mechanism ensures that all changes generated during the downtime are fully aggregated, with no risk of data loss or version fragmentation.

[0013] In one embodiment, the method further includes: receiving a switchover notification message broadcast by a temporary central server; in response to the switchover notification message, associating the client's main version tree and the synchronization source of the object storage to the temporary central server; receiving a recovery notification message broadcast by the recovered central server or the temporary central server; and in response to the recovery notification message, reassociating the client's main version tree and the synchronization source of the object storage back to the central server.

[0014] In the above technical solution, the client can smoothly migrate the synchronization source of the primary version tree and object storage from the original central server to a temporary central server without manual intervention, based on the received switch notification message. Similarly, after receiving a recovery notification message, it can automatically re-associate the synchronization source back to the recovered central server. The entire process is transparent to the user, effectively avoiding collaboration interruptions or configuration errors caused by server failures or recovery.

[0015] In one embodiment, when generating a version identifier for the differential storage object, the identifier, user identifier information, and the content hash value of the differential storage object are concatenated into a string to generate the version identifier; wherein, the identifier is used to characterize the version tree type to which the differential storage object belongs, including a main version tree identifier or a secondary version tree identifier; the user identifier information is used to uniquely identify the client that generated the differential storage object.

[0016] In the above technical solution, by concatenating the version tree type identifier and user identification information before the hash value, the generated complete version identifier still has global uniqueness even if the content hashes are the same, fundamentally eliminating the risk of version misjudgment or overwriting caused by hash collisions.

[0017] Secondly, embodiments of this application provide a version management control method, which is applied to a central server, including: The system receives a difference storage object sent by the client through the first transmission link and temporarily stores the difference storage object in the cache. The client receives a difference description file sent via a second transmission link. The difference description file is used to characterize the structural differences between the client's main version tree and slave version tree. In response to the merge instruction for the difference description file, merge the difference storage objects associated with the difference description file in the cache into the object storage of the central server; release the merged difference storage objects in the cache. Update information representing the version tree update of the central server is generated and sent to a pre-configured receiving end via a second transmission link to trigger the client to perform version tree synchronization.

[0018] In the above technical solution, the central server temporarily stores the difference storage objects uploaded by the client through the first transmission link in the cache area, instead of writing them directly to the main object storage; simultaneously, the associated difference storage objects are only formally merged into the object storage upon receiving an explicit merge instruction. This mechanism effectively isolates the commit and merge phases, preventing unreviewed or conflict-unresolved changes from directly polluting the repository, significantly enhancing the system's security and controllability. Meanwhile, the difference description file is delivered independently through the second transmission link, allowing the server to parse the version tree change intent in advance; while the difference storage objects are asynchronously transmitted and temporarily stored through the first transmission link. This dual-channel asynchronous reception and cache association design allows the central server to perform metadata verification, permission checks, or conflict prediction before content transmission is complete, improving processing efficiency and reducing the risk of transaction failures due to network fluctuations. After successful merge, the central server generates update information and sends it to the pre-configured receiving end through the second transmission link. This update message does not contain large objects; it only transmits structural change signals. Based on this, the client performs a synchronization operation that only updates the version tree structure, achieving low-bandwidth, high-delivery team status broadcasting. This ensures that all members are aware of the version evolution of the central server in a timely manner, reducing merge conflicts caused by status lag.

[0019] In one embodiment, after the central server recovers from a failed state to a normal online state, the method further includes: Receive version data pushed by a temporary central server, wherein the temporary central server is a client designated to replace the central server; The version tree and server object storage of the central server are updated based on the version data. A recovery notification message is generated and sent to a pre-configured receiving end via a second transmission link, so that the client can re-associate the synchronization source back to the central server.

[0020] In the above technical solution, during the downtime of the central server, a designated client acts as a temporary central server to continue receiving submissions from the team, forming an effective disaster recovery relay. When the original central server recovers, by actively receiving and merging all version data pushed by the temporary server, all changes during the failure window can be completely restored, avoiding data loss or version breaks and ensuring the continuity and integrity of the enterprise's digital assets.

[0021] Thirdly, embodiments of this application provide a version management control system, which is deployed on a client side, including: Local object storage is configured to store all objects generated locally by the client. The primary version tree is configured to track the version status of the central server and associate stored objects in the local object store with object references; From the version tree, it is configured to record version commits generated locally by the client and associate the stored objects in the local object store with object references; The submission processing module is configured to, in response to a version submission command, extract a difference storage object from the local object storage based on the comparison result between the main version tree and the secondary version tree, and generate a difference description file; wherein, the difference storage object represents incremental change data of the file content, and the difference description file is used to represent the structural differences between the main version tree and the secondary version tree; The first communication module is configured to send the difference storage object to the cache of the central server via a first transmission link, and to send the difference description file to a pre-configured receiving end via a second transmission link.

[0022] In one embodiment, a synchronization module is further included, configured to, in response to a version update instruction, obtain update information pushed by a central server from the receiving end through the second transmission link, and apply the update information to the main version tree to achieve version tree synchronization; wherein, the version tree synchronization only updates the structural information of the version tree and does not trigger the automatic transmission of stored objects; The synchronization module is also configured to, upon detecting an access request for the target storage object, respond to a user-triggered pull command, pull the target storage object from the central server via the first transmission link, and store the target storage object in the local object storage.

[0023] Fourthly, embodiments of this application provide a version management control system, which is deployed on a central server, including: The buffer is configured to temporarily store differential storage objects sent by the client via the first transmission link; The second communication module is configured to receive the difference description file sent by the client through the second transmission link, and send update information or recovery notification messages to the pre-configured receiving end; The merge processing module is configured to, in response to a merge instruction, merge the difference storage object associated with the difference description file in the cache into the object storage of the central server, and release the merged difference storage object. The version tree management module is configured to update the version tree of the central server based on the difference description file or version data pushed by the temporary central server, and generate update information representing the update of the central server's version tree. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application will be described below.

[0025] Figure 1This is a flowchart illustrating one implementation of the version management control method disclosed in this application.

[0026] Figure 2 This is a flowchart illustrating another implementation of the version management control method disclosed in the embodiments of this application.

[0027] Figure 3 This is a schematic diagram illustrating one implementation of the version management control system disclosed in this application.

[0028] Figure 4 This is a schematic diagram illustrating another implementation of the version management control system disclosed in this application.

[0029] Figure 5 This is a schematic diagram illustrating the connection between the client and the central server as disclosed in an embodiment of this application.

[0030] Explanation of reference numerals in the attached figures: 10-Client, 11-Local object storage, 12-Main version tree, 13-Slave version tree, 14-Commit processing module, 15-First communication module 20-Central server, 21-Cache area, 22-Second communication module, 23-Merge processing module, 24-Version tree management module, 25-Server object storage; 30 - Receiver, 40 - Version identifier generation module, 50 - Difference storage object, 60 - Difference description file, 70 - First transmission link, 80 - Second transmission link. Detailed Implementation

[0031] The embodiments of this application are described below with reference to the accompanying drawings.

[0032] In one embodiment, see Figure 1 and Figure 5 As shown, this application discloses a version management control method applied to a client 10, comprising: in response to receiving a version commit instruction, based on the comparison result between the main version tree 12 and the secondary version tree 13 of the client 10, extracting a difference storage object 50 from the local object storage 11, and generating a difference description file 60 for version metadata. The difference storage object 50 represents incremental change data of file content, and the difference description file 60 is used to represent the structural differences between the main version tree 12 and the secondary version tree 13. The difference storage object 50 is sent to the cache 21 of the central server 20 via a first transmission link 70; the difference description file 60 is sent to a pre-configured receiving end 30 via a second transmission link 80.

[0033] In this embodiment, the difference storage object and the difference description file are sent independently to the central server's cache and a pre-configured receiving end via the first transmission link and the second transmission link, respectively. This mechanism avoids uploading complete files or large snapshots, thereby significantly reducing network bandwidth usage and submission latency. It is especially suitable for weak network environments or large-scale codebase scenarios, and helps improve the developer submission experience and system response speed.

[0034] Furthermore, because the client's master version tree is configured to continuously track the version status of the central server, it ensures that the view of enterprise digital assets on the client side remains consistent with that of the central server, which is beneficial for integrity maintenance and audit traceability. Simultaneously, the slave version tree allows developers to submit versions locally offline. Based on this, when the central server temporarily fails, the system can dynamically designate a client that is aligned with the central server's state—that is, a client whose master version tree structure is consistent with the central server and can provide complete storage objects—as a temporary trusted source, thereby avoiding development process interruptions. Thus, while retaining the advantages of centralized governance based on a "single trusted source," it effectively improves the availability and resilience of the development process.

[0035] For example, the first transmission link 70 uses the HTTP or SSH protocol, the second transmission link 80 uses SMTP (Simple Mail Transfer Protocol), and the pre-configured receiving end 30 is a mailbox server.

[0036] For example, when a user initiates a version commit operation on the client, the client's intercom module (i.e., the communication and processing unit) first compares its locally maintained primary version tree 12 with its secondary version tree 13. The primary version tree 12 tracks the current version status of the central server 20, while the secondary version tree 13 records changes made in the user's local workspace. Based on the structural differences between the primary and secondary version trees 12 and 13, the intercom module identifies newly added, modified, or deleted file paths and directory nodes. Subsequently, the intercom module traverses the storage objects corresponding to these changes, extracts the binary data blocks (blobs) of the actual content changes from the local object storage 11, and combines these incremental change data into a difference storage object 50. This difference storage object 50 only contains the incremental content involved in this commit, rather than a full file snapshot, thus significantly reducing the amount of data to be transmitted. Simultaneously, the intercom module generates a difference description file 60, for example, organized in .xml format, to structurally describe the metadata differences between the primary and secondary version trees 12 and 13.

[0037] After completing the above preparations, client 10 pushes the difference storage object 50, i.e., the blob data packet, to the buffer 21 of central server 20 via the first transmission link 70. The intercom module on the central server 20 receives and temporarily stores the data, awaiting a merge command. Simultaneously, client 10 sends the difference description file 60 to a pre-configured receiving end 30 via the second transmission link 80. In this example, the receiving end 30 is an internal enterprise mail server, and the XML file is carried in the email subject or attachment, allowing development team members, CI / CD systems, or code review tools to promptly learn the details of the structural changes submitted without immediately downloading large binary content.

[0038] In a preferred embodiment of this application, the version management control method further includes, in response to receiving a version update instruction, obtaining update information pushed by the central server 20 through the second transmission link 80, and applying the update information to the main version tree 12 of the client 10 to achieve version tree synchronization; wherein, the version tree synchronization only updates the structural information of the version tree and does not trigger the automatic transmission of storage objects; when an access request for a target storage object is detected, in response to a pull instruction triggered by the user, the target storage object is pulled from the server object storage 25 of the central server 20 through the first transmission link 70. This process only involves the metadata of the version tree and does not transmit any storage objects, thereby significantly reducing network bandwidth consumption and synchronization latency, enabling developers to quickly perceive the latest status of the central repository, which is especially suitable for high-frequency collaboration or large-scale team scenarios. After the main version tree 12 is synchronized, the client 10 only holds the complete version structure index locally, while the underlying storage objects remain on the central server 20. When a user actually accesses a specific file and triggers a pull instruction, the system downloads the corresponding target storage object from the central server 20 through the first transmission link 70. This mechanism effectively avoids redundant downloads of the entire object, significantly saving local storage space and network resources.

[0039] For example, see Figure 5 As shown, the process of the central server 20 communicating with the client 10 is lightweight. When the version tree of the version tree management module 24 of the central server 20 is updated, it triggers the intercom to capture the version tree differences, generate an .xml file, and broadcast it to all clients 20 via SMTP, i.e., the second transmission link 80. At this time, when the client 20 views the version tree, it will immediately obtain the push notification from the central server 20 from the mail server 30. The client 10's local main version tree 12 will be synchronized with the central server 20, but the client 10 will not automatically receive blobs from the central server 20. Only when the client 10 performs local operations can it obtain the blob from the central server 20 via HTTP / SSH, i.e., the first transmission link 70.

[0040] In a preferred embodiment of this application, when client 10 is designated as a temporary central server, the method further includes: broadcasting a switchover notification message to other clients 10, so that the other clients 10 associate the synchronization source with this client. When the original central server 20 is detected to have recovered, the version data generated during the switchover is pushed to the recovered central server 20.

[0041] This preferred embodiment promotes client 10, whose primary version tree structure is consistent with the central server and which can provide complete object storage, to a temporary central server. This allows the client to continue receiving version commits and broadcasting change notifications from other clients 10, thereby maintaining team collaboration continuity and significantly improving system resilience. When the original central server 20 returns to online, the temporary central server proactively pushes all version data received and managed during the switchover back to the original central server 20. The central server 20 then updates its version tree and object storage accordingly and broadcasts a recovery notification, guiding all clients 10 to re-associate with the central server 20. This mechanism ensures that all changes generated during the downtime are fully aggregated, with no risk of data loss or version breakage.

[0042] In a preferred embodiment of this application, the method further includes: receiving a switchover notification message broadcast by a temporary central server; in response to the switchover notification message, associating the client 10's primary version tree 12 and the synchronization source of the object storage to the temporary central server; receiving a recovery notification message broadcast by the recovered central server 20 or the temporary central server; and in response to the recovery notification message, re-associating the client 10's primary version tree 12 and the synchronization source of the object storage back to the central server 20. The client 10 can smoothly migrate its primary version tree and the synchronization source of the object storage from the original central server to the temporary central server without manual intervention, based on the received switchover notification message; similarly, after receiving the recovery notification message, it can automatically re-associate the synchronization source back to the recovered central server 20. The entire process is transparent to the user, effectively avoiding collaboration interruptions or configuration errors caused by server failures or recovery.

[0043] In a preferred embodiment of this application, when the version identifier generation module 40 generates a version identifier for the differential storage object 50, it concatenates an identifier, user identifier information, and the content hash value of the differential storage object to generate the version identifier. The identifier represents the version tree type to which the differential storage object belongs, including a primary version tree identifier or a secondary version tree identifier. The user identifier information uniquely identifies the client that generated the differential storage object. By concatenating the version tree type identifier and user identifier information before the hash value, even if different storage objects experience hash collisions, the concatenated version identifier will remain globally unique because their primary and secondary version tree types (i.e., different identifiers) or generating clients (i.e., different user identifier information) are different. This fundamentally eliminates the risk of version misjudgment or overwriting caused by hash collisions.

[0044] A hash collision occurs when two distinct data objects, calculated using the same hash algorithm, unexpectedly produce the exact same hash value. In version control, hash values ​​serve as unique identifiers for stored objects and version data. Collisions can cause different, differing stored objects to be assigned the same identifier, leading to misinterpretations of data by the system, resulting in issues such as version referencing confusion and the incorrect overwriting of legitimate data.

[0045] In one embodiment, see Figure 2 and Figure 5 As shown in the figure, this application discloses a version management control method applied to a central server 20, including: receiving a difference storage object 50 sent by a client 10 through a first transmission link 70, and temporarily storing the difference storage object 50 in a cache 21. Receiving a difference description file 60 sent by the client 10 through a second transmission link 80, the difference description file 60 is used to characterize the structural differences between the client 10's main version tree 12 and the secondary version tree 13. In response to a merge instruction for the difference description file 60, merging the difference storage object 50 associated with the difference description file 60 in the cache 21 into the central server 20's object storage, i.e., server object storage 25, and releasing the merged difference storage object 50 in the cache 21. Generating update information characterizing the version tree update of the central server 20, and sending the update information to a pre-configured receiving end 30 through the second transmission link 80 to trigger the client 10 to perform main version tree synchronization.

[0046] In this preferred embodiment, the central server 20 temporarily stores the difference storage object 50 uploaded by the client 10 via the first transmission link 70 in the cache area 21, instead of directly writing it to the main object storage; simultaneously, the associated difference storage object 50 is only formally merged into the object storage after receiving an explicit merge instruction. This mechanism effectively isolates the commit and merge stages, preventing unreviewed or conflict-unresolved changes from directly polluting the repository, significantly enhancing the system's security and controllability. Meanwhile, the difference description file 60 is delivered independently via the second transmission link 80, allowing the central server 20 to parse the version tree change intent in advance; while the difference storage object 50 is asynchronously transmitted and temporarily stored via the first transmission link 70. This dual-channel asynchronous reception and cache association design allows the central server 20 to perform metadata verification, permission checks, or conflict prediction before content transmission is complete, improving processing efficiency and reducing the risk of transaction failures due to network fluctuations. After successful merge, the central server 20 generates update information and sends it to the pre-configured receiving end 30 via the second transmission link 80. This update information does not contain large objects; it only transmits structural change signals. Based on this, client 10 performs a synchronization operation that only updates the version tree structure, achieving low-bandwidth, high-delivery team status broadcasting. This ensures that all members are aware of the version evolution of the central server 20 in a timely manner, reducing merge conflicts caused by status lag.

[0047] For example, after client 10 completes the information push, central server 20 obtains all version tree files pushed by client 10 from mail server, i.e., receiving end 30. In merge processing module 23, it completes the splicing of master and slave version trees and the compression of versions pushed by client 10. After merge arbitration, the blob that wins the arbitration, i.e. the difference storage object 50, will be merged into the object of central server 20, i.e. the server object storage 26. The dialog will release the buffer 21 and clear the transmission content from client 10.

[0048] In a preferred embodiment of this application, after the central server 20 recovers from a failed state to a normal online state, the method further includes: receiving version data pushed by a temporary central server, wherein the temporary central server is a client 10 designated to replace the central server; updating the version tree and server object storage 25 of the central server 20 based on the version data; generating a recovery notification message and sending the recovery notification message to a pre-configured receiving end 30 through a second transmission link 80, so that the client 10 re-associates the synchronization source back to the central server.

[0049] When the central server 20 crashes or goes offline, a client 10 with a complete version tree and objects can be selected as a temporary central server. The selected client 20 is activated as the temporary central server via the master-slave identification component in the repository, and the intercom broadcasts the remote information of the temporary central server to other clients 10 via the second transmission link 80. Upon receiving the notification from the temporary central server, other clients 10 update their local master version tree 12 to remotely associate with the temporary central server, and subsequently, other clients 10 can continue to push versions to the unique "trusted source".

[0050] During the downtime of central server 20, designated client 10 acts as a temporary central server to continue receiving team submissions, forming an effective disaster recovery relay. When the original central server 20 recovers, by actively receiving and merging all version data pushed by the temporary server, all changes during the failure window can be fully restored, avoiding data loss or version breaks and ensuring the continuity and integrity of the enterprise's digital assets.

[0051] In one embodiment, see Figure 3 and Figure 5 As shown, this application embodiment provides a version management control system, which is deployed on client 20, including: Local object storage 11 is configured to store all storage objects generated locally by client 10; The main version tree 12 is configured to track the version status of the central server 20 and associate the stored objects in the local object store 11 with object references; Version tree 13 is configured to record version commits generated locally by client 10 and associate the stored objects in local object storage 11 with object references; The submission processing module 14 is configured to, in response to a version submission command, extract a difference storage object 50 from the local object storage 11 based on the comparison result between the main version tree 12 and the secondary version tree 13, and generate a difference description file 60; wherein, the difference storage object 50 represents incremental change data of the file content, and the difference description file 60 is used to represent the structural differences between the main version tree 12 and the secondary version tree 13; The first communication module 15 is configured to send the difference storage object 50 to the cache 21 of the central server 20 via the first transmission link 70, and to send the difference description file 60 to the pre-configured receiving end 30 via the second transmission link 80.

[0052] As a preferred embodiment of this application, the version management control system disclosed in this application further includes a synchronization module, configured to, in response to a version update command, obtain update information pushed by the central server 20 from the receiving end through the second transmission link 80, and apply the update information to the main version tree 12 to achieve version tree synchronization; wherein, the version tree synchronization only updates the structural information of the version tree and does not trigger the automatic transmission of storage objects; the synchronization module is also configured to, when detecting an access request for a target storage object, in response to a pull command triggered by the user, pull the target storage object from the central server through the first transmission link, and store the target storage object in the local object storage.

[0053] In one embodiment, see Figure 4 and Figure 5 As shown in the figure, this application discloses a version management control system, which is deployed on a central server 20, including: Buffer 21 is configured to temporarily store the difference storage object 50 sent by client 10 through the first transmission link 70; The second communication module 22 is configured to receive the difference description file 60 sent by the client 10 through the second transmission link, and send update information or recovery notification messages to the pre-configured receiving end 30. The merge processing module 23 is configured to, in response to a merge instruction, merge the difference storage object 50 associated with the difference description file 60 in the cache 21 into the server object storage 25 of the central server 20, and release the merged difference storage object 50 in the cache 21.

[0054] The version tree management module 24 is configured to update the version tree of the central server 20 based on the difference description file 60 or the version data pushed by the temporary central server, and generate update information representing the version tree update of the central server 20.

[0055] In summary, the version control system disclosed in this application possesses the characteristics of a centralized version control system. It has a single "trusted source" as the central server 20, but all client 10 repository copies do not rely on the central server 20 to obtain version information. Each client 10 repository copy has two version trees: a secondary version tree 13 associated with version commits generated in the client 10's working directory, and a primary version tree 12 associated with the version on the central server 20. Therefore, even if the central server 20 fails, client 10 can still iterate on the secondary version tree 13 locally. In the system, when an update occurs in the repository on the central server 20, a broadcast dialogue is triggered, pushing the update information of its version tree to all client 10 members in the repository. When a user operates on the version tree in the client 10 repository, they automatically receive an update notification from the central server 20 through the dialogue platform. The configuration file obtained from the notification updates the primary version tree 12 in the client 10's copy repository. Client 10 users can choose whether to immediately synchronize stored objects to their local machine based on the commit information in the primary version tree 12. Similarly, when client 10 pushes a version update to central server 20, it also notifies central server 20 of the update via a dialogue. However, client 20 also needs to push the difference storage object 50 to the staging area 21 of central server 20. When the manager of central server 21 selects all clients 10 to push to, it merges the corresponding difference storage object 50 from staging area 21 into central server 20's server object storage 25, and releases staging area 21, updates the version tree, and broadcasts the notification. Furthermore, when central server 20 fails, a client 10 whose version tree and object storage are aligned with central server 20 can be selected, and its replica repository can be used as a temporary central server. This temporary central server will then broadcast to all client 10 members, and the primary version tree 12 and object storage of all client 10 members will be re-associated according to the notification, maintaining a single "trusted source" control in the system. When central server 20 recovers, the temporary central server can push the version from the period of failure to central server 20.

[0056] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A version management control method, characterized in that: Applied to the client side, including: In response to receiving a version commit instruction, based on the comparison results between the client's main version tree and the secondary version tree, a difference storage object is extracted from the local object storage, and a difference description file of version metadata is generated; wherein, the difference storage object represents the incremental change data of the file content, and the difference description file is used to represent the structural differences between the main version tree and the secondary version tree; The differential storage object is sent to the cache of the central server via the first transmission link; The difference description file is sent to a pre-configured receiving end via a second transmission link.

2. The version management control method according to claim 1, characterized in that, Also includes: In response to receiving a version update instruction, the system obtains the update information pushed by the central server through the second transmission link and applies the update information to the client's main version tree to achieve version tree synchronization. The version tree synchronization only updates the structural information of the version tree and does not trigger the automatic transmission of the stored object. When an access request for the target stored object is detected, in response to a pull instruction triggered by the user, the system pulls the target stored object from the central server through the first transmission link.

3. The version management control method according to claim 1, characterized in that, When a client is designated as a temporary central server, the method further includes: broadcasting a switchover notification message to other clients so that the other clients associate the synchronization source with this client; and pushing the version data generated during the switchover to the restored central server when the original central server is detected to be restored.

4. The version management control method according to claim 1, characterized in that, Also includes: Receive the switchover notification message broadcast by the temporary central server; In response to the switching notification message, the client's main version tree and the synchronization source of the object storage are associated with the temporary central server; Receive recovery notification messages broadcast by the recovered central server or the temporary central server; In response to the recovery notification message, the client's main version tree and the synchronization source of the object storage are re-associated with the central server.

5. The version management control method according to claim 1, characterized in that: After retrieving the differential storage object from the local object storage, the method further includes: generating a version identifier for the differential storage object by concatenating the identifier, user identifier information, and the content hash value of the differential storage object into a string to generate the version identifier; The identifier is used to characterize the version tree type to which the difference storage object belongs, including the primary version tree identifier or the secondary version tree identifier; the user identification information is used to uniquely identify the client that generated the difference storage object.

6. A version management control method, characterized in that: Applications to central servers include: The system receives a differential storage object sent by the client through the first transmission link and temporarily stores the differential storage object in the cache. The client receives a difference description file sent via a second transmission link. The difference description file is used to characterize the structural differences between the client's main version tree and slave version tree. In response to the merge instruction for the difference description file, merge the difference storage objects associated with the difference description file in the cache into the object storage of the central server; release the merged difference storage objects in the cache. Update information representing the version tree update of the central server is generated and sent to a pre-configured receiving end via a second transmission link to trigger the client to perform version tree synchronization.

7. The version management control method according to claim 6, characterized in that: After the central server recovers from a failed state to a normal online state, the method further includes: Receive version data pushed by a temporary central server, wherein the temporary central server is a client designated to replace the central server; The version tree and server object storage of the central server are updated based on the version data. A recovery notification message is generated and sent to a pre-configured receiving end via a second transmission link, so that the client can re-associate the synchronization source back to the central server.

8. A version management control system, characterized in that: Deployed on the client side, including: Local object storage is configured to store all objects generated locally by the client. The primary version tree is configured to track the version status of the central server and associate stored objects in the local object store with object references; From the version tree, it is configured to record version commits generated locally by the client and associate the stored objects in the local object store with object references; The submission processing module is configured to, in response to a version submission command, extract a difference storage object from the local object storage based on the comparison result between the main version tree and the secondary version tree, and generate a difference description file; wherein, the difference storage object represents incremental change data of the file content, and the difference description file is used to represent the structural differences between the main version tree and the secondary version tree; The first communication module is configured to send the difference storage object to the cache of the central server via a first transmission link, and to send the difference description file to a pre-configured receiving end via a second transmission link.

9. The version management control system according to claim 8, characterized in that: It also includes a synchronization module, configured to respond to a version update command, obtain update information pushed by the central server from the receiving end through the second transmission link, and apply the update information to the main version tree to achieve version tree synchronization; wherein, the version tree synchronization only updates the structural information of the version tree and does not trigger the automatic transmission of stored objects; The synchronization module is also configured to, upon detecting an access request for the target storage object, respond to a user-triggered pull command, pull the target storage object from the central server via the first transmission link, and store the target storage object in the local object storage.

10. A version management control system, characterized in that: Deployed on a central server, including: The buffer is configured to temporarily store differential storage objects sent by the client via the first transmission link; The second communication module is configured to receive the difference description file sent by the client through the second transmission link, and send update information or recovery notification messages to the pre-configured receiving end; The merge processing module is configured to, in response to a merge instruction, merge the difference storage object associated with the difference description file in the cache into the object storage of the central server, and release the merged difference storage object. The version tree management module is configured to update the version tree of the central server based on the difference description file or version data pushed by the temporary central server, and generate update information representing the update of the central server's version tree.

Images