Data synchronization method and apparatus, electronic device, and storage medium
By performing synchronization update checks and conflict handling on the preset synchronized repository, the complexity of data synchronization between different version managers is resolved, enabling flexible two-way synchronization and efficient project development.
Patent Information
- Application Number
- CN202310380747.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-04-10
- Publication Date
- 2025-11-21
- Estimated Expiration
- 2043-04-10
AI Technical Summary
Existing two-way synchronization tools require complex configurations during data synchronization between different version managers, resulting in insufficient flexibility.
By responding to commit notifications from the version manager, the system performs a synchronization update check on the preset synchronized repositories, determines whether the first and second repositories are synchronized, and performs synchronization updates on the corresponding branches when they are not synchronized, resolves conflicting data, and uses a preset conflict handling strategy for synchronization updates.
It enables flexible two-way synchronization between different version managers, improving the flexibility and efficiency of project development and resolving the problem of synchronizing conflicting data.
Smart Images

Figure CN116628080B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data processing technology, and in particular to a data synchronization method, apparatus, electronic device, and storage medium. Background Technology
[0002] Version managers are commonly used in team collaboration projects in the field of software development. Commonly used version managers include Git and SVN (i.e., Subversion). Since different version managers have different characteristics and different development roles have different preferences, different development roles or developers may use different version managers for the same development project. Therefore, data synchronization between different version managers can meet the application needs of using different version managers for the same development project.
[0003] Existing bidirectional synchronization tools typically require complex configurations in their respective data warehouses, including branch configurations and permission configurations, which are too restrictive and lack flexibility. Summary of the Invention
[0004] In view of this, the purpose of the present invention is to provide a data synchronization method, apparatus, electronic device and storage medium to improve the flexibility of bidirectional synchronization between different version managers.
[0005] In a first aspect, embodiments of the present invention provide a data synchronization method, the method comprising: responding to a commit notification from any version manager, performing a synchronization update check on a preset synchronization repository to obtain a synchronization check result, the synchronization check result being used to indicate whether a first repository and a second repository in the preset synchronization repository are synchronized, the first repository including target project data indicated by a first version manager, and the second repository including target project data indicated by a second version manager; if the first repository and the second repository in the preset synchronization repository are not synchronized, then based on the commit information of the data to be synchronized, performing a synchronization update on the corresponding branches of the first repository and the second repository, and during the synchronization update process, determining whether the data to be synchronized conflicts; if the data to be synchronized conflicts, then performing a synchronization update on the conflicting data to be synchronized according to a preset conflict handling strategy to obtain a synchronization update result.
[0006] Secondly, embodiments of the present invention provide a data synchronization device, comprising: a checking module, configured to perform a synchronization update check on a preset synchronization repository in response to a commit notification from any version manager, and obtain a synchronization check result, wherein the synchronization check result is used to indicate whether a first repository and a second repository in the preset synchronization repository are synchronized, wherein the first repository includes target project data indicated by a first version manager, and the second repository includes target project data indicated by a second version manager; a synchronization module, configured to, if the first repository and the second repository in the preset synchronization repository are not synchronized, perform a synchronization update on the corresponding branches of the first repository and the second repository based on the commit information of the data to be synchronized, and determine whether the data to be synchronized conflicts during the synchronization update process; and a correction module, configured to, if the data to be synchronized conflicts, perform a synchronization update on the conflicting data to be synchronized according to a preset conflict handling strategy, and obtain a synchronization update result.
[0007] Thirdly, embodiments of the present invention provide an electronic device, including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the above-described data synchronization method.
[0008] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to implement the aforementioned data synchronization method.
[0009] The embodiments of the present invention bring the following beneficial effects:
[0010] The aforementioned data synchronization method, apparatus, electronic device, and storage medium, in response to a commit notification from any version manager, perform a synchronization update check on a preset synchronization repository to obtain a synchronization check result. This result indicates whether a first repository and a second repository within the preset synchronization repository are synchronized. The first repository includes target project data indicated by a first version manager, and the second repository includes target project data indicated by a second version manager. If the first and second repositories in the preset synchronization repository are not synchronized, then based on the commit information of the data to be synchronized, the corresponding branches of the first and second repositories are synchronized and updated. During the synchronization update process, it is determined whether the data to be synchronized conflicts. If the data to be synchronized conflicts, then the conflicting data to be synchronized is synchronized and updated according to a preset conflict handling strategy to obtain a synchronization update result. In this approach, for target projects managed by different version managers, when any version manager commits, a synchronization check is performed on the target project data indicated by the two version managers in the preset synchronization repository. Based on the commit information of the data to be synchronized, the corresponding branches of the data to be synchronized are synchronized and the synchronization of conflicting data is resolved, thus improving the flexibility of bidirectional synchronization between different version managers.
[0011] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.
[0012] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0013] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0014] Figure 1 This is a flowchart of one embodiment of the data synchronization method in this invention;
[0015] Figure 2 This is a flowchart of another embodiment of the data synchronization method in this invention;
[0016] Figure 3A schematic diagram of a data synchronization device provided in an embodiment of the present invention;
[0017] Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0019] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” or “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0020] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 One embodiment of the data synchronization method in this invention includes:
[0021] Step S10: In response to a commit notification from any version manager, perform a synchronization update check on the preset synchronization repository to obtain a synchronization check result. The synchronization check result is used to indicate whether the first repository and the second repository in the preset synchronization repository are synchronized. The first repository includes the target project data indicated by the first version manager, and the second repository includes the target project data indicated by the second version manager.
[0022] It should be noted that the preset synchronization repository includes target project data indicated by the first version manager and target project data indicated by the second version manager. That is, the target project data for the same target project managed by different version managers is included in the preset synchronization repository. Terminals using different version managers can manage the same target project together with terminals using another version manager without changing their version manager, improving the flexibility of project development. In this embodiment, when a terminal using any version manager submits an update, it simultaneously sends a submission notification to the server. The server responds to the submission notification from any version manager by performing a synchronization update check on the preset synchronization repository in the server, obtaining the synchronization check result, thereby determining whether the first and second repositories in the preset synchronization repository are synchronized. In other words, it determines whether the target project data indicated by the two different version managers (i.e., the first version manager and the second version manager) in the preset synchronization repository are synchronized, thus determining whether to perform subsequent synchronization updates for both.
[0023] It should be noted that commit notifications from any version manager can be sent by any version manager terminal / server that controls the target project data. For example, for the same target project being developed collaboratively by a team, any terminal / server used by any team member to manage the version of the target project data can send a commit notification when committing updated data to the remote repository where the target project data resides, thereby triggering synchronization between the first and second repositories in the preset synchronization repository. It is understood that the remote repository where the target project data resides can be on the same server as the preset synchronization repository, or it can be on a different server. For example, if all terminals 'a' using the SVN version manager uniformly commit the target project data to server A, and each terminal 'a' commits updated data to server A and pulls updated data committed by other terminals 'a' from server A, then the preset synchronization repository can be on server A or on another server; this is not limited here. Similarly, assuming all terminals 'b' using the Git version manager uniformly commit the target project data to server B, then each terminal 'b' can commit updated data to server B and pull updated data committed by other terminals 'b' from server B; therefore, the preset synchronization repository can be on server B or on another server; this is not limited here. Based on this, assuming that the first repository contains the target project data indicated by the Git version manager and the second repository contains the target project data indicated by the SVN version manager, then the first repository in the preset synchronization repository will always be consistent with the target project data indicated by the Git version manager on server B, and the second repository in the preset synchronization repository will always be consistent with the target project data indicated by the SVN version manager on server A. The preset synchronization repository can be located on server A, B or other servers, and is not limited here.
[0024] It is understood that the first repository includes the target project data indicated by the first version manager, and the second repository includes the target project data indicated by the second version manager. For example, assuming the first version manager is Git and the second version manager is SVN, then the first repository contains the target project data indicated by Git, and the second repository contains the target project data indicated by SVN; the specifics are not limited here. The first and second repositories in the preset synchronization repository are pre-synchronized repositories, meaning the target project data in the first and second repositories are pre-synchronized, the target project data is the same, but the version managers used are different. This implementation uses a preset synchronization repository for bidirectional synchronization, enabling version management of the same target project using different version managers without the need for version manager conversion or repository migration, thus improving the flexibility of version managers in the project.
[0025] In one implementation, since the first and second repositories in the preset synchronization repository are pre-synchronized, when performing a synchronization update check on the preset synchronization repository, the synchronization status of the first and second repositories can be determined by checking whether updates exist in the first and second repositories. If updates exist in the first and / or second repositories, it indicates that the first and second repositories in the preset synchronization repository are not synchronized, thereby quickly determining the synchronization status of the preset synchronization repository and improving the efficiency of bidirectional synchronization between different version managers.
[0026] Step S20: If the first and second repositories in the preset synchronization repository are not synchronized, then based on the commit information of the data to be synchronized, the corresponding branches of the first and second repositories are synchronized and updated, and during the synchronization update process, it is determined whether the data to be synchronized has a conflict.
[0027] It should be noted that if the first and second repositories in the preset synchronization repository are out of sync, it indicates that there are differences between the files in the first and second repositories. To resolve these differences and resynchronize the first and second repositories, based on the commit information of the data to be synchronized (i.e., the differing data), the first and second repositories are updated with data from the same branch. The commit information indicates the data related to the commit of the data to be synchronized. For example, the commit information could indicate at least one file to be synchronized, the modifications to each file, the committer information for each file, the modification time of each file, and the branch information for each file, etc. Specific details are not limited here. Furthermore, during the synchronization update process, conflict detection is performed on the data to be synchronized to determine if any conflicts have occurred. The data to be synchronized contains at least one file. It can be understood that if the same file to be synchronized in both the first and second repositories needs to be updated during the synchronization update process, then a conflict has occurred. For example, suppose the first repository contains target project data indicated by the Git version manager, and the second repository contains target project data indicated by the SVN version manager. If both the terminal managing the target project through the Git version manager and the terminal managing the target project through the SVN version manager modify and commit the update of file 1 in the target project data, then file 1 is conflicting data to be synchronized. It needs to be conditionally synchronized and updated according to the preset conflict handling strategy in the next step, so as to realize the synchronization update of conflicting data.
[0028] It is understandable that for any version control indicating the target project data, updated data is committed to a specific branch, such as the main branch of Git or a custom branch created by the user. Therefore, the branch information in the commit information of the data to be synchronized refers to the branch to which the data to be synchronized was committed. For example, if the terminal managing the target project through the Git version control commits the data to be synchronized to the main branch, then the branch information includes the information of the main branch. Specific details are not limited here. In one implementation, the branches of the first and second repositories are pre-mapped in the preset synchronization repository. When performing synchronization updates on corresponding branches, the data to be synchronized in the first repository can be synchronized to the second repository and / or the data to be synchronized in the second repository can be synchronized to the first repository using the pre-mapped branch information, thus improving the flexibility of projects managed by different version control systems.
[0029] In one implementation, a conflict can be determined by comparing the data to be synchronized in a first repository and a second repository. Specifically, during the synchronization update process, the data to be synchronized in the first repository is compared with the data to be synchronized in the second repository to obtain a comparison result. The comparison result indicates whether there is any data in the first repository that is identical to the data to be synchronized in the second repository. A conflict is determined based on the comparison result. If there is data in the first repository that is identical to the data to be synchronized in the second repository, a conflict is determined, and the conflicting data to be synchronized is obtained. If there is no data in the first repository that is identical to the data to be synchronized in the second repository, no conflict is determined, and the synchronization update result is obtained. This implementation can solve the problem of file modification conflicts when different version managers manage the same project data, thus improving the flexibility of different version managers managing the same project.
[0030] Step S30: If a conflict occurs in the data to be synchronized, the conflicting data to be synchronized is updated according to the preset conflict handling strategy to obtain the synchronization update result.
[0031] In this embodiment, during the synchronization update process, for data to be synchronized without conflict, the corresponding branch can be directly synchronized and updated. For data to be synchronized with conflict, the corresponding branch is synchronized and updated according to a preset conflict handling strategy to obtain the final synchronization update result. For example, suppose the data to be synchronized includes files 1, 2, and 3 in the first repository, where files 1 and 2 are data to be synchronized without conflict, and file 3 is data to be synchronized with conflict. Then, during the synchronization update process, files 1 and 2 can be directly synchronized to the corresponding branch in the second repository, while file 3 is synchronized and updated according to the preset conflict handling strategy, thereby obtaining the synchronization update result.
[0032] In one implementation, a preset conflict resolution strategy is used to instruct a base version manager. When a conflict occurs in the synchronization data, the base version manager, as instructed by the preset conflict resolution strategy, determines whether the conflicting data to be synchronized is the target project data indicated by the base version manager. If so, the conflicting data to be synchronized is used as the base, and the conflicting data to be synchronized overwrites the data to be synchronized in another repository, resulting in a synchronization update. If the conflicting data to be synchronized is not the target project data indicated by the base version manager, the data to be synchronized in another repository is used to overwrite the conflicting data to be synchronized, resulting in a synchronization update. For example, assuming the preset conflict resolution strategy instructs the base version manager to be a Git version manager, when the Git version manager and the SVN version manager are updating the same file to be synchronized simultaneously, the Git version manager is used as the base, overwriting the target project data indicated by the SVN version manager. That is, the data to be synchronized submitted by the Git version manager terminal overwrites the data to be synchronized submitted by the SVN version manager terminal, thereby resolving the conflict and achieving synchronization.
[0033] The data synchronization method provided by the above embodiments, for target projects that use different version managers for version management, when any version manager makes a commit, performs a synchronization check on the target project data indicated by the two version managers in the preset synchronization repository, and updates the corresponding branch of the data to be synchronized according to the commit information of the data to be synchronized, so that the target project data indicated by the two version managers remain synchronized and can resolve the synchronization of conflicting data, thereby improving the flexibility of bidirectional synchronization between different version managers.
[0034] Please see Figure 2 Another embodiment of the data synchronization method in this invention includes:
[0035] Step S201: In response to a commit notification from any version manager, perform a synchronization update check on the preset synchronization repository to obtain a synchronization check result. The synchronization check result is used to indicate whether the first repository and the second repository in the preset synchronization repository are synchronized. The first repository includes the target project data indicated by the first version manager, and the second repository includes the target project data indicated by the second version manager.
[0036] In one embodiment, step S201 includes: when a commit command from any version manager triggers a hook function, in response to the commit notification sent by the hook function, performing a synchronization update check on the first and second repositories in the preset synchronization repository to obtain a synchronization check result. In this embodiment, when the terminal of any version manager commits update data for the target project, the hook function (i.e., the hook function) is triggered through the terminal of that version manager, and a commit notification is sent through the hook function. The server, in response to the commit notification sent by the hook function, triggers a synchronization update check on the first and second repositories in the preset synchronization repository, thereby obtaining a synchronization check result. This embodiment, through the hook function, can immediately trigger synchronization updates in the repositories indicated by different version managers when update data is committed from the terminal of any version manager, thereby improving the real-time performance of bidirectional synchronization between different version managers, avoiding collaborative development problems caused by untimely synchronization, and improving the flexibility of project development.
[0037] In one implementation, step S201 includes: in response to a commit notification from any version manager, performing an update check on a first repository in a preset synchronization repository to obtain a first check result, the first check result indicating whether there is data to be synchronized in the first repository; performing an update check on a second repository in the preset synchronization repository to obtain a second check result, the second check result indicating whether there is data to be synchronized in the second repository; if the first check result indicates that there is data to be synchronized in the first repository, and / or the second check result indicates that there is data to be synchronized in the second repository, then determining that the synchronization check result indicates that the first and second repositories in the preset synchronization repository are not synchronized; if the first check result indicates that there is no data to be synchronized in the first repository, and the second check result indicates that there is no data to be synchronized in the second repository, then determining that the synchronization check result indicates that the first and second repositories in the preset synchronization repository are synchronized.
[0038] Understandably, when performing a synchronization update check on the preset synchronization repository, the system first checks if the first repository has updates, obtaining a first check result, and then checks if the second repository has updates, obtaining a second check result. If either the first or second repository contains data to be synchronized, or if both repositories contain data to be synchronized, it indicates that the first and second repositories in the preset synchronization repository are not synchronized; conversely, if neither the first nor the second repository contains data to be synchronized, it indicates that the first and second repositories in the preset synchronization repository are synchronized. In one implementation, the data to be synchronized refers to the update data submitted by any version manager terminal. The preset synchronization repository obtains the first and second repositories by pulling the target project data indicated by the first and second version managers, respectively. Then, it performs update checks on the first and second repositories to determine if the target project data indicated by the first and second version managers has been updated. If so, the preset synchronization repository performs a synchronization update to ensure that the target project data indicated by the first and second version managers is consistent, thereby improving the flexibility of project management by different version managers. It should be noted that the target project data indicated by the first and second version managers refers to the baseline data of the target project, and all version manager terminals develop projects based on this baseline data.
[0039] In one embodiment, before step S201, the method further includes: creating a preset synchronization repository, and retrieving target project data indicated by a first version manager and target project data indicated by a second version manager from the preset synchronization repository to obtain a first repository and a second repository in the preset synchronization repository; based on the first ignored file list of the first repository and the second ignored file list of the second repository, synchronizing non-ignored files in the first repository and the second repository in the preset synchronization repository to obtain a pre-synchronized first repository and a second repository in the preset synchronization repository. In this embodiment, the preset synchronization repository includes a pre-synchronized first repository and a second repository. When performing pre-synchronization of the first repository and the second repository, the target project data indicated by the first version manager is first retrieved to obtain the first repository in the preset synchronization repository, and the target project data indicated by the second version manager is retrieved to obtain the second repository in the preset synchronization repository; then, according to the first ignored file list of the first repository and the second ignored file list of the second repository, the non-ignored files in the first repository and the second repository in the preset synchronization repository are synchronized to obtain a pre-synchronized first repository and a second repository in the preset synchronization repository. Non-ignored files include target project files outside the first ignored file list and the second ignored file list. This embodiment can ignore specific files and not perform synchronization updates, thereby improving synchronization update efficiency.
[0040] Furthermore, if the first version manager is used to instruct the Git version manager, then the first list of ignored files can be stored in .gitignore; if the second version manager is used to instruct the SVN version manager, then the second list of ignored files can be set in the configuration file or through the propset directive, which is not limited here.
[0041] Step S202: If the first and second warehouses in the preset synchronization warehouse are not synchronized, determine the address information of the data to be synchronized in another warehouse based on the submission information of the data to be synchronized. The submission information includes branch information.
[0042] It's important to note that in repositories managed by different version control systems, each branch corresponds to a repository address. Submitting updates to different branches actually means submitting updates to different branch addresses. Therefore, when synchronizing corresponding branches in the first and second repositories, the address of the data to be synchronized in the other repository can be determined based on the branch information in the commit message. This allows the data to be uploaded to the corresponding address in the other repository, thus achieving synchronized updates for the corresponding branches. For example, assuming the first version control system is Git, and the branch information in the commit message includes the name of the main branch (e.g., master), meaning the data to be synchronized is the update data on the main branch, then the address of the data to be synchronized in the corresponding repository can be generated based on the preset repository address common segment and the name of the main branch. This address can be a URL, such as a LAN URL or WAN URL, etc., without specific limitations here. For example, assuming the repository address common segment is http: / / xxx.com, the address could be http: / / xxx.com / master or http: / / xxx.com / trunk, etc., without specific limitations here.
[0043] In one implementation, step S202 includes: if the first and second repositories in the preset synchronization repository are not synchronized, then based on the commit information of the data to be synchronized, the data to be synchronized is committed to the branch corresponding to the other repository through a preset permission account, and the commit information of the data to be synchronized in the other repository is recorded, resulting in a commit record of the data to be synchronized in the other repository. The commit record includes the committer information, commit version information, repository information, and commit time information of the data to be synchronized; during the commit process, it is determined whether the data to be synchronized has a conflict. In this implementation, to avoid the situation where a commit account of a version manager does not have commit permissions in the repository indicated by another version manager, causing bidirectional synchronization failure, a permission account (i.e., a preset permission account) is pre-configured and granted bidirectional commit permissions to avoid the above situation. For example, assuming the first version manager is a Git version manager and the second version manager is an SVN version manager, when the Git version manager terminal commits update data, the update data committed by the Git version manager terminal is synchronized to the target project data indicated by the SVN version manager through the preset permission account A, thereby achieving synchronization between the first and second repositories. In this implementation, to clarify the source of the target project data—that is, to determine which version control manager committed the data—when committing the data to be synchronized to the corresponding branch of another repository, the commit information of the data to be synchronized in the current repository is also committed, generating a commit record. This commit record includes, but is not limited to, committer information, commit version information, repository information, and commit time information. For example, when the Git version control manager terminal commits updated data, the committer A, commit version 1, Git repository information, and commit time are recorded in the log file of the second repository indicated by the SVN version control manager, thereby generating a commit record for easy viewing and tracing of each commit.
[0044] Step S203: Based on the address information, send the data to be synchronized to the address corresponding to another warehouse, and determine whether the data to be synchronized conflicts with the data in the other warehouse;
[0045] Understandably, once the address information of the data to be synchronized in another repository is determined, the data to be synchronized can be sent to the corresponding address in the other repository, thereby synchronizing the data to be synchronized to the corresponding branch in the other repository, and determining whether the data to be synchronized conflicts with the data to be synchronized in the other repository.
[0046] In one implementation, a first version manager is used to instruct a Git version manager, and a second version manager is used to instruct an SVN version manager. Step S203 includes: determining whether the address indicated by the address information exists in another repository; if the address indicated by the address information does not exist in another repository, obtaining a target branch from a preset branch pool, establishing a mapping relationship between the target branch and the address information, and obtaining the address indicated by the address information in another repository, which is used to instruct the second repository; sending the data to be synchronized to the address corresponding to the other repository, and determining whether the data to be synchronized conflicts with the data in the other repository. In this implementation, when the repository indicated by the Git version manager synchronizes data to the repository indicated by the SVN version manager, in order to perform the synchronization update of the corresponding branch, it first determines whether the address indicated by the address information of the Git version manager exists in the repository indicated by the SVN version manager (i.e., the second repository). If it does not exist, obtaining a target branch from a preset branch pool, establishing a mapping relationship between the target branch and the address information, thereby obtaining the address indicated by the address information in the second repository, and submitting the data to be synchronized to the address corresponding to the second repository. The target branch can be a branch with an empty address or a branch with a preset address; the specific choice is not limited here. Furthermore, when establishing the mapping relationship between the target branch and the address information, the target branch can be directly modified to the address corresponding to the address information. This implementation pre-occupies some branches by using a preset branch pool, which avoids the situation where branches are already occupied when creating a branch. Moreover, when creating a new branch, it can quickly establish a branch mapping relationship with another version manager, without being limited by complex mapping configurations in two version managers, thereby improving the flexibility of bidirectional synchronization between different version managers.
[0047] Furthermore, in one embodiment, the method further includes: in response to a deletion instruction for any branch in the first repository, reclaiming any branch through a preset branch pool.
[0048] It should be noted that when any branch in the first repository is deleted, the address of that branch in the second repository is recycled to the preset branch pool for use in the next creation.
[0049] Step S204: If a conflict occurs in the data to be synchronized, the conflicting data to be synchronized is updated according to the preset conflict handling strategy to obtain the synchronization update result.
[0050] In one implementation, step S204 includes: if a conflict occurs in the data to be synchronized, determining whether the data to be synchronized is the same as the data to be synchronized in the base repository according to a preset conflict handling strategy. The base repository is used to indicate either the first repository or the second repository. If the data to be synchronized is the same as the data to be synchronized in the base repository, then the data to be synchronized is overwritten in the other repository to obtain a synchronization update result. In this implementation, the preset conflict handling strategy is used to indicate the base repository, which can be either the first repository or the second repository. If the base repository is the first repository, then when the data to be synchronized is the same as the data to be synchronized in the first repository, the data to be synchronized is overwritten in the other repository to resolve the conflict. For example, assuming the base repository is the repository indicated by the Git version manager, when the update data submitted by the Git version manager terminal conflicts with the update data submitted by the SVN version manager terminal, the update data submitted by the Git version manager terminal directly overwrites the update data submitted by the SVN version manager terminal, thereby obtaining a synchronization update result.
[0051] In one implementation, step S204 includes: if a conflict occurs in the data to be synchronized, determining whether the data to be synchronized contains a file of the target file type according to a preset conflict handling strategy; if the data to be synchronized contains a file of the target file type, then the data to be synchronized is overwritten in another repository to obtain a synchronization update result. In this implementation, the preset conflict handling strategy is used to indicate the target file type. If the data to be synchronized contains a file of the target file type, then for files with the same file name, the file of the target file type can overwrite the file of the target file type in another repository that is not of the target file type. Specific details are not limited here.
[0052] The data synchronization method provided by the above embodiments, for target projects that use different version managers for version management, when any version manager makes a commit, performs a synchronization check on the target project data indicated by the two version managers in the preset synchronization repository, and updates the corresponding branch of the data to be synchronized according to the commit information of the data to be synchronized, so that the target project data indicated by the two version managers remain synchronized and can resolve the synchronization of conflicting data, thereby improving the flexibility of bidirectional synchronization between different version managers.
[0053] For the corresponding method embodiments described above, see [link to relevant documentation]. Figure 3The diagram illustrates a data synchronization device, which includes: a checking module 30, configured to perform a synchronization update check on a preset synchronization repository in response to a commit notification from any version manager, and obtain a synchronization check result. The synchronization check result indicates whether a first repository and a second repository in the preset synchronization repository are synchronized. The first repository includes target project data indicated by a first version manager, and the second repository includes target project data indicated by a second version manager. A synchronization module 32, configured to perform a synchronization update on the corresponding branches of the first repository and the second repository based on the commit information of the data to be synchronized if the first repository and the second repository in the preset synchronization repository are not synchronized, and determine whether the data to be synchronized conflicts during the synchronization update process. A correction module 34, configured to perform a synchronization update on the conflicting data to be synchronized according to a preset conflict handling strategy if a conflict occurs, and obtain a synchronization update result.
[0054] The aforementioned data synchronization device, for target projects using different version managers for version management, performs a synchronization check on the target project data indicated by the two version managers in the preset synchronization repository when any version manager commits. Based on the commit information of the data to be synchronized, it performs synchronization updates on the corresponding branches of the data to be synchronized, so that the target project data indicated by the two version managers remain synchronized and can resolve the synchronization of conflicting data, thereby improving the flexibility of bidirectional synchronization between different version managers.
[0055] Optionally, the above synchronization module 32 includes: a determining unit, used to determine the address information of the data to be synchronized in another warehouse according to the submission information of the data to be synchronized if the first warehouse and the second warehouse in the preset synchronization warehouse are not synchronized, wherein the submission information includes branch information; and a sending unit, used to send the data to be synchronized to the address corresponding to the other warehouse according to the address information, and to determine whether the data to be synchronized conflicts with the data in the other warehouse.
[0056] Optionally, the first version manager is used to instruct the Git version manager, and the second version manager is used to instruct the SVN version manager; the sending unit is also used to: determine whether the address indicated by the address information exists in another repository; if the address indicated by the address information does not exist in another repository, obtain the target branch from the preset branch pool, and establish a mapping relationship between the target branch and the address information to obtain the address indicated by the address information in another repository, which is used to instruct the second repository; send the data to be synchronized to the address corresponding to the other repository, and determine whether the data to be synchronized conflicts with the data in the other repository.
[0057] Optionally, the above device further includes: a recycling module, used to recycle any branch in response to a deletion command of any branch in the first warehouse through a preset branch pool.
[0058] Optionally, the above-mentioned checking module is also used to: when a commit command from any version manager triggers a hook function, in response to the commit notification sent by the hook function, perform a synchronization update check on the first and second repositories in the preset synchronization repository, and obtain the synchronization check result.
[0059] Optionally, the above-mentioned checking module is further configured to: in response to a commit notification from any version manager, perform an update check on the first repository in the preset synchronization repository to obtain a first check result, the first check result being used to indicate whether there is data to be synchronized in the first repository; perform an update check on the second repository in the preset synchronization repository to obtain a second check result, the second check result being used to indicate whether there is data to be synchronized in the second repository; if the first check result indicates that there is data to be synchronized in the first repository, and / or the second check result indicates that there is data to be synchronized in the second repository, then determine that the synchronization check result indicates that the first repository and the second repository in the preset synchronization repository are not synchronized; if the first check result indicates that there is no data to be synchronized in the first repository, and the second check result indicates that there is no data to be synchronized in the second repository, then determine that the synchronization check result indicates that the first repository and the second repository in the preset synchronization repository are synchronized.
[0060] Optionally, the above synchronization module is also used to: if the first and second repositories in the preset synchronization repository are not synchronized, then based on the submission information of the data to be synchronized, submit the data to be synchronized to the branch corresponding to the other repository through the preset permission account, and record the submission information of the data to be synchronized in the other repository to obtain the submission record of the data to be synchronized in the other repository. The submission record includes the submitter information, submission version information, repository information, and submission time information of the data to be synchronized; during the submission process, determine whether the data to be synchronized has a conflict.
[0061] Optionally, the above correction module is also used to: if a conflict occurs in the data to be synchronized, determine whether the data to be synchronized is the data to be synchronized in the reference warehouse according to the preset conflict handling strategy, the reference warehouse is used to indicate the first warehouse or the second warehouse; if the data to be synchronized is the data to be synchronized in the reference warehouse, then overwrite the data to be synchronized in another warehouse to obtain the synchronization update result.
[0062] Optionally, the above correction module is also used to: if a conflict occurs in the data to be synchronized, determine whether the data to be synchronized contains a file of the target file type to be synchronized according to a preset conflict handling strategy; if the data to be synchronized contains a file of the target file type to be synchronized, then overwrite the data to be synchronized in another repository to obtain the synchronization update result.
[0063] Optionally, the above apparatus further includes: a creation module, used to create a preset synchronization repository, and pull target project data indicated by a first version manager and target project data indicated by a second version manager from the preset synchronization repository to obtain a first repository and a second repository in the preset synchronization repository; and an ignore module, used to synchronize non-ignore files in the first repository and the second repository in the preset synchronization repository based on a first ignore file list in the first repository and a second ignore file list in the second repository to obtain a pre-synchronized first repository and a second repository in the preset synchronization repository.
[0064] This embodiment also provides an electronic device, including a processor and a memory. The memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the above-described data synchronization method. This electronic device can be a server or a terminal device.
[0065] See Figure 4 As shown, the electronic device includes a processor 100 and a memory 101. The memory 101 stores machine-executable instructions that can be executed by the processor 100. The processor 100 executes the machine-executable instructions to implement the above-described data synchronization method.
[0066] Furthermore, Figure 4 The electronic device shown also includes a bus 102 and a communication interface 103, with the processor 100, the communication interface 103 and the memory 101 connected via the bus 102.
[0067] The memory 101 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network. The bus 102 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.
[0068] Processor 100 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 100 or by instructions in software form. Processor 100 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 101. The processor 100 reads information from memory 101 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments, for example:
[0069] In response to a commit notification from any version manager, a synchronization update check is performed on the preset synchronization repository to obtain a synchronization check result. The synchronization check result is used to indicate whether the first repository and the second repository in the preset synchronization repository are synchronized. The first repository includes the target project data indicated by the first version manager, and the second repository includes the target project data indicated by the second version manager. If the first repository and the second repository in the preset synchronization repository are not synchronized, the corresponding branches of the first repository and the second repository are synchronized based on the commit information of the data to be synchronized. During the synchronization update process, it is determined whether the data to be synchronized has a conflict. If the data to be synchronized has a conflict, the conflicting data to be synchronized is synchronized according to the preset conflict handling strategy to obtain a synchronization update result.
[0070] In this approach, for target projects using different version managers for version management, when a commit occurs in either version manager, a synchronization check is performed on the target project data indicated by the two version managers in the preset synchronization repository. Based on the commit information of the data to be synchronized, the corresponding branch of the data to be synchronized is updated, so that the target project data indicated by the two version managers remains synchronized and the synchronization of conflicting data can be resolved, thus improving the flexibility of bidirectional synchronization between different version managers.
[0071] Optionally, if the first and second warehouses in the preset synchronization warehouse are not synchronized, then based on the submission information of the data to be synchronized, the corresponding branches of the first and second warehouses are synchronized and updated. During the synchronization update process, it is determined whether the data to be synchronized conflicts, including: if the first and second warehouses in the preset synchronization warehouse are not synchronized, then based on the submission information of the data to be synchronized, the address information of the data to be synchronized in another warehouse is determined, the submission information including branch information; based on the address information, the data to be synchronized is sent to the address corresponding to the other warehouse, and it is determined whether the data to be synchronized conflicts with the data in the other warehouse.
[0072] Optionally, the first version manager is used to instruct the Git version manager, and the second version manager is used to instruct the SVN version manager; based on the address information, the data to be synchronized is sent to the address corresponding to another repository, and it is determined whether the data to be synchronized conflicts with the data in the other repository, including: determining whether the address indicated by the address information exists in the other repository; if the address indicated by the address information does not exist in the other repository, the target branch is obtained from the preset branch pool, and a mapping relationship between the target branch and the address information is established to obtain the address indicated by the address information in the other repository, which is used to instruct the second repository; the data to be synchronized is sent to the address corresponding to the other repository, and it is determined whether the data to be synchronized conflicts with the data in the other repository.
[0073] Optionally, the method also includes: in response to a deletion command for any branch in the first repository, reclaiming any branch through a preset branch pool.
[0074] Optionally, in response to a commit notification from any version manager, a synchronization update check is performed on the preset synchronization repository to obtain the synchronization check result, including: when a commit command from any version manager triggers a hook function, in response to the commit notification sent by the hook function, a synchronization update check is performed on the first and second repositories in the preset synchronization repository to obtain the synchronization check result.
[0075] Optionally, in response to a commit notification from any version manager, a synchronization update check is performed on a preset synchronization repository to obtain a synchronization check result, including: in response to a commit notification from any version manager, an update check is performed on a first repository in the preset synchronization repository to obtain a first check result, the first check result being used to indicate whether there is data to be synchronized in the first repository; an update check is performed on a second repository in the preset synchronization repository to obtain a second check result, the second check result being used to indicate whether there is data to be synchronized in the second repository; if the first check result indicates that there is data to be synchronized in the first repository, and / or the second check result indicates that there is data to be synchronized in the second repository, then it is determined that the synchronization check result indicates that the first repository and the second repository in the preset synchronization repository are not synchronized; if the first check result indicates that there is no data to be synchronized in the first repository, and the second check result indicates that there is no data to be synchronized in the second repository, then it is determined that the synchronization check result indicates that the first repository and the second repository in the preset synchronization repository are synchronized.
[0076] Optionally, if the first and second repositories in the preset synchronization repository are not synchronized, then based on the commit information of the data to be synchronized, the corresponding branches of the first and second repositories are synchronized and updated. During the synchronization update process, it is determined whether the data to be synchronized has a conflict, including: if the first and second repositories in the preset synchronization repository are not synchronized, then based on the commit information of the data to be synchronized, the data to be synchronized is committed to the corresponding branch of another repository through a preset permission account, and the commit information of the data to be synchronized in the other repository is recorded, so as to obtain the commit record of the data to be synchronized in the other repository. The commit record includes the committer information, commit version information, repository information, and commit time information of the data to be synchronized; during the commit process, it is determined whether the data to be synchronized has a conflict.
[0077] Optionally, if a conflict occurs in the data to be synchronized, the conflicting data to be synchronized is updated according to a preset conflict handling strategy to obtain a synchronization update result, including: if a conflict occurs in the data to be synchronized, it is determined according to the preset conflict handling strategy whether the data to be synchronized is the data to be synchronized in the reference warehouse, the reference warehouse is used to indicate the first warehouse or the second warehouse; if the data to be synchronized is the data to be synchronized in the reference warehouse, the data to be synchronized is overwritten in another warehouse to obtain a synchronization update result.
[0078] Optionally, if a conflict occurs in the data to be synchronized, the conflicting data to be synchronized is updated according to a preset conflict handling strategy to obtain a synchronization update result, including: if a conflict occurs in the data to be synchronized, determining whether the data to be synchronized contains a file of the target file type to be synchronized according to the preset conflict handling strategy; if the data to be synchronized contains a file of the target file type to be synchronized, then the data to be synchronized is overwritten to another repository to obtain a synchronization update result.
[0079] Optionally, before performing a synchronization update check on the preset synchronization repository in response to a commit notification from any version manager and obtaining the synchronization check result, the method further includes: creating a preset synchronization repository, and pulling target project data indicated by the first version manager and target project data indicated by the second version manager from the preset synchronization repository to obtain a first repository and a second repository in the preset synchronization repository; based on the first ignored file list of the first repository and the second ignored file list of the second repository, synchronizing the non-ignored files of the first repository and the second repository in the preset synchronization repository to obtain a pre-synchronized first repository and a second repository in the preset synchronization repository.
[0080] This embodiment also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are invoked and executed by a processor, they cause the processor to implement the aforementioned data synchronization method, for example:
[0081] In response to a commit notification from any version manager, a synchronization update check is performed on the preset synchronization repository to obtain a synchronization check result. The synchronization check result is used to indicate whether the first repository and the second repository in the preset synchronization repository are synchronized. The first repository includes the target project data indicated by the first version manager, and the second repository includes the target project data indicated by the second version manager. If the first repository and the second repository in the preset synchronization repository are not synchronized, the corresponding branches of the first repository and the second repository are synchronized based on the commit information of the data to be synchronized. During the synchronization update process, it is determined whether the data to be synchronized has a conflict. If the data to be synchronized has a conflict, the conflicting data to be synchronized is synchronized according to the preset conflict handling strategy to obtain a synchronization update result.
[0082] In this approach, for target projects using different version managers for version management, when a commit occurs in either version manager, a synchronization check is performed on the target project data indicated by the two version managers in the preset synchronization repository. Based on the commit information of the data to be synchronized, the corresponding branch of the data to be synchronized is updated, so that the target project data indicated by the two version managers remains synchronized and the synchronization of conflicting data can be resolved, thus improving the flexibility of bidirectional synchronization between different version managers.
[0083] Optionally, if the first and second warehouses in the preset synchronization warehouse are not synchronized, then based on the submission information of the data to be synchronized, the corresponding branches of the first and second warehouses are synchronized and updated. During the synchronization update process, it is determined whether the data to be synchronized conflicts, including: if the first and second warehouses in the preset synchronization warehouse are not synchronized, then based on the submission information of the data to be synchronized, the address information of the data to be synchronized in another warehouse is determined, the submission information including branch information; based on the address information, the data to be synchronized is sent to the address corresponding to the other warehouse, and it is determined whether the data to be synchronized conflicts with the data in the other warehouse.
[0084] Optionally, the first version manager is used to instruct the Git version manager, and the second version manager is used to instruct the SVN version manager; based on the address information, the data to be synchronized is sent to the address corresponding to another repository, and it is determined whether the data to be synchronized conflicts with the data in the other repository, including: determining whether the address indicated by the address information exists in the other repository; if the address indicated by the address information does not exist in the other repository, the target branch is obtained from the preset branch pool, and a mapping relationship between the target branch and the address information is established to obtain the address indicated by the address information in the other repository, which is used to instruct the second repository; the data to be synchronized is sent to the address corresponding to the other repository, and it is determined whether the data to be synchronized conflicts with the data in the other repository.
[0085] Optionally, the method also includes: in response to a deletion command for any branch in the first repository, reclaiming any branch through a preset branch pool.
[0086] Optionally, in response to a commit notification from any version manager, a synchronization update check is performed on the preset synchronization repository to obtain the synchronization check result, including: when a commit command from any version manager triggers a hook function, in response to the commit notification sent by the hook function, a synchronization update check is performed on the first and second repositories in the preset synchronization repository to obtain the synchronization check result.
[0087] Optionally, in response to a commit notification from any version manager, a synchronization update check is performed on a preset synchronization repository to obtain a synchronization check result, including: in response to a commit notification from any version manager, an update check is performed on a first repository in the preset synchronization repository to obtain a first check result, the first check result being used to indicate whether there is data to be synchronized in the first repository; an update check is performed on a second repository in the preset synchronization repository to obtain a second check result, the second check result being used to indicate whether there is data to be synchronized in the second repository; if the first check result indicates that there is data to be synchronized in the first repository, and / or the second check result indicates that there is data to be synchronized in the second repository, then it is determined that the synchronization check result indicates that the first repository and the second repository in the preset synchronization repository are not synchronized; if the first check result indicates that there is no data to be synchronized in the first repository, and the second check result indicates that there is no data to be synchronized in the second repository, then it is determined that the synchronization check result indicates that the first repository and the second repository in the preset synchronization repository are synchronized.
[0088] Optionally, if the first and second repositories in the preset synchronization repository are not synchronized, then based on the commit information of the data to be synchronized, the corresponding branches of the first and second repositories are synchronized and updated. During the synchronization update process, it is determined whether the data to be synchronized has a conflict, including: if the first and second repositories in the preset synchronization repository are not synchronized, then based on the commit information of the data to be synchronized, the data to be synchronized is committed to the corresponding branch of another repository through a preset permission account, and the commit information of the data to be synchronized in the other repository is recorded, so as to obtain the commit record of the data to be synchronized in the other repository. The commit record includes the committer information, commit version information, repository information, and commit time information of the data to be synchronized; during the commit process, it is determined whether the data to be synchronized has a conflict.
[0089] Optionally, if a conflict occurs in the data to be synchronized, the conflicting data to be synchronized is updated according to a preset conflict handling strategy to obtain a synchronization update result, including: if a conflict occurs in the data to be synchronized, it is determined according to the preset conflict handling strategy whether the data to be synchronized is the data to be synchronized in the reference warehouse, the reference warehouse is used to indicate the first warehouse or the second warehouse; if the data to be synchronized is the data to be synchronized in the reference warehouse, the data to be synchronized is overwritten in another warehouse to obtain a synchronization update result.
[0090] Optionally, if a conflict occurs in the data to be synchronized, the conflicting data to be synchronized is updated according to a preset conflict handling strategy to obtain a synchronization update result, including: if a conflict occurs in the data to be synchronized, determining whether the data to be synchronized contains a file of the target file type to be synchronized according to the preset conflict handling strategy; if the data to be synchronized contains a file of the target file type to be synchronized, then the data to be synchronized is overwritten to another repository to obtain a synchronization update result.
[0091] Optionally, before performing a synchronization update check on the preset synchronization repository in response to a commit notification from any version manager and obtaining the synchronization check result, the method further includes: creating a preset synchronization repository, and pulling target project data indicated by the first version manager and target project data indicated by the second version manager from the preset synchronization repository to obtain a first repository and a second repository in the preset synchronization repository; based on the first ignored file list of the first repository and the second ignored file list of the second repository, synchronizing the non-ignored files of the first repository and the second repository in the preset synchronization repository to obtain a pre-synchronized first repository and a second repository in the preset synchronization repository.
[0092] The computer program products of the data synchronization method, apparatus, electronic device and storage medium provided in the embodiments of the present invention include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.
[0093] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0094] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.
[0095] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0096] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.
[0097] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, 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 the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A data synchronization method, characterized in that, The method includes: In response to a commit notification from any version manager, a synchronization update check is performed on a preset synchronization repository to obtain a synchronization check result. The synchronization check result is used to indicate whether the first repository and the second repository in the preset synchronization repository are synchronized. The first repository includes the target project data indicated by the first version manager, and the second repository includes the target project data indicated by the second version manager. If the first and second warehouses in the preset synchronization warehouse are not synchronized, then based on the submission information of the data to be synchronized, the corresponding branches of the first and second warehouses are synchronized and updated, and during the synchronization update process, it is determined whether the data to be synchronized has a conflict. If the data to be synchronized conflicts, the conflicting data to be synchronized will be updated according to the preset conflict handling strategy to obtain the synchronization update result. In response to a commit notification from any version manager, a synchronization update check is performed on a preset synchronization repository to obtain the synchronization check results, including: In response to a commit notification from any version manager, an update check is performed on the first repository in the preset synchronization repository to obtain a first check result. The first check result is used to indicate whether there is data to be synchronized in the first repository. An update check is performed on the second warehouse in the preset synchronization warehouse to obtain a second check result, which is used to indicate whether there is data to be synchronized in the second warehouse. If the first check result indicates that there is data to be synchronized in the first warehouse, and / or the second check result indicates that there is data to be synchronized in the second warehouse, then it is determined that the synchronization check result indicates that the first warehouse and the second warehouse in the preset synchronization warehouse are not synchronized; If the first check result indicates that there is no data to be synchronized in the first warehouse, and the second check result indicates that there is no data to be synchronized in the second warehouse, then the synchronization check result indicates that the first warehouse and the second warehouse in the preset synchronization warehouse are synchronized.
2. The method according to claim 1, characterized in that, If the first and second repositories in the preset synchronization repository are not synchronized, then based on the submission information of the data to be synchronized, the corresponding branches of the first and second repositories are synchronized and updated. During the synchronization update process, it is determined whether the data to be synchronized conflicts, including: If the first and second warehouses in the preset synchronization warehouses are not synchronized, the address information of the data to be synchronized in another warehouse is determined according to the submission information of the data to be synchronized, and the submission information includes branch information. Based on the address information, the data to be synchronized is sent to the address corresponding to another warehouse, and it is determined whether the data to be synchronized conflicts with the data in the other warehouse.
3. The method according to claim 2, characterized in that, The first version manager is used to instruct the Git version manager, and the second version manager is used to instruct the SVN version manager; The step of sending the data to be synchronized to the address corresponding to another warehouse according to the address information, and determining whether the data to be synchronized conflicts with the data in the other warehouse, includes: Determine whether the address indicated by the address information exists in another warehouse; If the address indicated by the address information does not exist in another warehouse, then the target branch is obtained from the preset branch pool, and a mapping relationship between the target branch and the address information is established to obtain the address indicated by the address information in another warehouse, which is used to indicate the second warehouse; The data to be synchronized is sent to the address corresponding to another warehouse, and it is determined whether the data to be synchronized conflicts with the data in the other warehouse.
4. The method according to claim 3, characterized in that, The method further includes: In response to a deletion command for any branch in the first repository, the branch is reclaimed through the preset branch pool.
5. The method according to claim 1, characterized in that, In response to a commit notification from any version manager, a synchronization update check is performed on a preset synchronization repository to obtain the synchronization check results, including: When a commit command from any version manager triggers a hook function, in response to the commit notification sent by the hook function, a synchronization update check is performed on the first and second repositories in the preset synchronization repository to obtain the synchronization check result.
6. The method according to claim 1, characterized in that, If the first and second repositories in the preset synchronization repository are not synchronized, then based on the submission information of the data to be synchronized, the corresponding branches of the first and second repositories are synchronized and updated. During the synchronization update process, it is determined whether the data to be synchronized conflicts, including: If the first and second repositories in the preset synchronization repository are not synchronized, then based on the submission information of the data to be synchronized, the data to be synchronized is submitted to the branch corresponding to the other repository through the preset permission account, and the submission information of the data to be synchronized in the other repository is recorded, so as to obtain the submission record of the data to be synchronized in the other repository. The submission record includes the submitter information, submission version information, repository information and submission time information of the data to be synchronized. During the submission process, it is determined whether the data to be synchronized has any conflicts.
7. The method according to claim 1, characterized in that, If a conflict occurs in the data to be synchronized, the conflicting data is synchronized and updated according to a preset conflict handling strategy to obtain a synchronization update result, including: If a conflict occurs in the data to be synchronized, it is determined whether the data to be synchronized is the data to be synchronized in the baseline warehouse according to the preset conflict handling strategy. The baseline warehouse is used to indicate the first warehouse or the second warehouse. If the data to be synchronized is the same as the data to be synchronized in the baseline repository, then the data to be synchronized is overwritten in another repository to obtain the synchronization update result.
8. The method according to claim 1, characterized in that, If a conflict occurs in the data to be synchronized, the conflicting data is synchronized and updated according to a preset conflict handling strategy to obtain a synchronization update result, including: If a conflict occurs in the data to be synchronized, the system will determine whether the data to be synchronized contains a file of the target file type to be synchronized, according to a preset conflict handling strategy. If the data to be synchronized contains files of the target file type, then the data to be synchronized is overwritten in another repository to obtain the synchronization update result. Specifically, for files to be synchronized with the same file name, the files of the target file type are overwritten in another repository to replace files of the non-target file type.
9. The method according to any one of claims 1-8, characterized in that, Before performing a synchronization update check on the preset synchronization repository in response to a commit notification from any version manager and obtaining the synchronization check result, the method further includes: Create a preset synchronization repository, and pull the target project data indicated by the first version manager and the target project data indicated by the second version manager from the preset synchronization repository to obtain the first repository and the second repository in the preset synchronization repository; Based on the first ignored file list of the first repository and the second ignored file list of the second repository, the first and second repositories in the preset synchronization repository are synchronized with non-ignored files to obtain the first and second repositories in the preset synchronization repository.
10. A data synchronization device, characterized in that, The device includes: The inspection module is used to perform a synchronization update check on a preset synchronization repository in response to a commit notification from any version manager, and obtain a synchronization check result. The synchronization check result is used to indicate whether the first repository and the second repository in the preset synchronization repository are synchronized. The first repository includes target project data indicated by the first version manager, and the second repository includes target project data indicated by the second version manager. The synchronization module is used to perform corresponding branch synchronization updates on the first and second warehouses based on the submission information of the data to be synchronized if the first and second warehouses in the preset synchronization warehouses are not synchronized, and to determine whether the data to be synchronized is conflicted during the synchronization update process. The correction module is used to synchronize and update the conflicting data according to a preset conflict handling strategy if a conflict occurs, so as to obtain a synchronization update result. The checking module is further configured to: in response to a commit notification from any version manager, perform an update check on the first repository in the preset synchronization repository to obtain a first check result, the first check result being used to indicate whether there is data to be synchronized in the first repository; perform an update check on the second repository in the preset synchronization repository to obtain a second check result, the second check result being used to indicate whether there is data to be synchronized in the second repository; if the first check result indicates that there is data to be synchronized in the first repository, and / or the second check result indicates that there is data to be synchronized in the second repository, then determine that the synchronization check result indicates that the first repository and the second repository in the preset synchronization repository are not synchronized; if the first check result indicates that there is no data to be synchronized in the first repository, and the second check result indicates that there is no data to be synchronized in the second repository, then determine that the synchronization check result indicates that the first repository and the second repository in the preset synchronization repository are synchronized.
11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the data synchronization method according to any one of claims 1-9.
12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the data synchronization method according to any one of claims 1-9.
Citation Information
Patent Citations
Method and device for displaying synchronous state, terminal and storage medium
CN110196662A
Data synchronization method and device, server, storage medium and product
CN114221971A