Complex model branch merging method based on optimal public ancestor

Abstract

The invention provides a complex model branch merging method based on an optimal public ancestor. The method comprises the following steps: constructing a version tree according to an information change history of each version; judging whether the two versions have public ancestors or not according to the path relation of the source version and the target version on the version tree, if so, selecting an optimal public ancestor from all the public ancestors, and respectively calculating first change data between the source version and the optimal public ancestor and second change data between the target version and the optimal public ancestor, combining the first change data and the second change data with the optimal public ancestor to obtain a combined version; and if not, calculating third change data between the source version and the target version, and merging the third change data with the target version to obtain a merged version. By applying the technical scheme provided by the invention, the technical problem that a branch merging method in the prior art is not suitable for multiple branch merging of a complex model due to potential conflict processing is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of version control, and in particular to a complex model branch merging method based on an optimal common ancestor. Background Art

[0002] With the rapid development of information technology and the popularization of multi-user collaborative work mode, people's demand for multi-user collaboration of complex models has increased significantly. Complex model version control is increasingly widely used in software engineering, system engineering, electronic engineering and other fields. It usually involves a large number of interactive elements and complex relationships, such as Unified Modeling Language (UML) models, System Modeling Language (SysML) models, Hardware Description Language (HDL) models, etc. Its complexity is not only due to its large scale and large number of elements, but also due to the intricate dependencies and associations between elements. As the core component for complex models to achieve multi-user collaboration, the version control system supports multiple modelers to complete model design work on the same model in parallel, and tracks and manages the historical changes of the model. With the increasing version iteration and modeling team, complex models may undergo multiple branch merges, forming an extremely complex version tree, and the probability of data anomalies in the branch merge process is greatly increased.

[0003] The key difficulty of traditional branch merging methods lies in the determination of common ancestors, which mainly rely on the three-way merge method, which performs the merge operation by comparing the differences between the two branches to be merged and their common ancestors. However, when looking for the common ancestor of two branches, such methods often ignore the context information and version numbers of historical submissions, and only perform mechanical merges based on text differences. They are not applicable to multiple branch merge scenarios of complex models. Their main limitations are as follows: 1) They are usually limited to the structure of linear text, and are not applicable to complex models containing multi-layer nested structures, non-linear relationships, specific semantic constraints, etc.; 2) They cannot accurately identify the change information that has been merged on a branch, which easily causes unnecessary repeated merges and increases the risk of merge conflicts; 3) When there are multiple common ancestors, traditional methods lack clear selection criteria, which increases the complexity and potential errors of merge operations. Summary of the invention

[0004] The present invention provides a complex model branch merging method based on an optimal common ancestor, which can solve the technical problem that the branch merging method in the prior art has potential conflict processing and is not suitable for multiple branch merging of complex models.

[0005] According to one aspect of the present invention, a complex model branch merging method based on an optimal common ancestor is provided, the method comprising:

[0006] S1, build a version tree based on the information change history of each version. Each node in the version tree corresponds to each submitted version. The parent node and child node corresponding to two versions with a parent-child relationship in the information change history are connected by a line, and the line points from the child node to the parent node. The nodes, lines and the directions of the lines constitute multiple branches of the version tree;

[0007] S2, define the two versions to be merged as the source version and the target version. When merging the source version to the target version, determine whether the two versions have a common ancestor based on the path relationship between the source version and the target version on the version tree. If yes, go to S3, if not, go to S4;

[0008] S3, selecting the best common ancestor from all common ancestors, respectively calculating the first change data between the source version and the best common ancestor and the second change data between the target version and the best common ancestor, merging the first change data and the second change data with the best common ancestor to obtain a merged version of the source version and the target version;

[0009] S4, calculating the third change data between the source version and the target version, and merging the third change data with the target version to obtain a merged version of the source version and the target version.

[0010] Further, judging whether the two versions have a common ancestor based on the path relationship between the source version and the target version in the version tree includes:

[0011] Determine whether the branch path of the source version on the version tree passes through the branch path of the target version on the version tree. If so, determine that the source version and the target version do not have a common ancestor. If not, determine that the source version and the target version have a common ancestor.

[0012] Further, selecting the best common ancestor from all common ancestors includes:

[0013] Calculate the sum of the path lengths from each common ancestor to the source version and the target version respectively;

[0014] The common ancestor with the smallest sum of path lengths is taken as the optimal common ancestor.

[0015] Furthermore, the common ancestor with the smallest sum of path lengths is taken as the optimal common ancestor, including:

[0016] When there are two or more paths whose sum of lengths is the same and the smallest, the common ancestor corresponding to the sum of lengths of the paths with the latest version is selected as the optimal common ancestor.

[0017] Further, merging the first change data and the second change data with the best common ancestor to obtain a merged version of the source version and the target version includes:

[0018] Determine whether there is a conflict between the first change data and the second change data. If not, apply both the first change data and the second change data to the best common ancestor to obtain a merged version of the source version and the target version. If yes, the user makes a trade-off decision on the conflicting change data in the first change data and the second change data to obtain the trade-off change data, and apply the trade-off change data to the best common ancestor to obtain a merged version of the source version and the target version.

[0019] Further, merging the third change data with the target version to obtain a merged version of the source version and the target version includes: applying the third change data to the target version to obtain a merged version of the source version and the target version.

[0020] Furthermore, the first change data, the second change data and the third change data all include structure change data, behavior change data, relationship change data, attribute change data and graphic change data.

[0021] The technical solution of the present invention is applied to provide a complex model branch merging method based on the best common ancestor. The method firstly constructs a version tree with the help of graph theory knowledge, significantly improves the system's ability to express and process complex version relationships, and gives it higher flexibility and accuracy; secondly, the path selection-based method provides preset rules and processes for judging the existence of common ancestors and locating the best common ancestor. Based on this rule and process, when there is no common ancestor, repeated conflict calculations can be avoided according to the branches and versions to be merged, and the best common ancestor can be reasonably determined when there is a common ancestor, so that the change information can be accurately identified and calculated, and the number of submissions between the best common ancestor and the source version and the target version can be minimized, effectively reducing the complexity and potential conflict of the change data, reducing manual conflict processing, and providing a guarantee for the stability of the branch merging method, thereby ensuring the accuracy, efficiency, consistency and traceability of the change data, significantly improving the stability of the version control system and user experience, and ensuring the stability and reliability of the version control system during multi-user collaboration. The method breaks through the limitation that the traditional method is only applicable to linear text files. By decomposing complex models into structures, behaviors, relationships, attributes, etc., and calculating changes based on the best common ancestor, the comprehensive version control of various model data can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The included drawings are used to provide a further understanding of the embodiments of the present invention, which constitute a part of the specification, are used to illustrate the embodiments of the present invention, and together with the text description, explain the principles of the present invention. Obviously, the drawings in the following description are only some embodiments of the present invention, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0023] Figure 1 A flowchart of a complex model branch merging method based on an optimal common ancestor provided according to a specific embodiment of the present invention is shown;

[0024] Figure 2 A schematic diagram of the optimal common ancestor positioning process provided according to a specific embodiment of the present invention is shown;

[0025] Figure 3 A schematic diagram of a version tree of a complex model provided according to a specific embodiment of the present invention is shown;

[0026] Figure 4 A schematic diagram of multiple merging of a branch merging method provided according to a specific embodiment of the present invention is shown. DETAILED DESCRIPTION

[0027] It should be noted that, in the absence of conflict, the embodiments in this application and the features in the embodiments can be combined with each other. The technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. The following description of at least one exemplary embodiment is actually only illustrative and is by no means intended to limit the present invention and its application or use. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0028] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present application. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, it indicates the presence of features, steps, operations, devices, components and / or combinations thereof.

[0029] Unless otherwise specifically stated, the relative arrangement of the parts and steps described in these embodiments, numerical expressions and numerical values ​​do not limit the scope of the present invention. At the same time, it should be understood that, for ease of description, the sizes of the various parts shown in the accompanying drawings are not drawn according to the actual proportional relationship. The technology, method and equipment known to ordinary technicians in the relevant field may not be discussed in detail, but in appropriate cases, the technology, method and equipment should be regarded as a part of the authorization specification. In all examples shown and discussed here, any specific value should be interpreted as being merely exemplary, rather than as a limitation. Therefore, other examples of exemplary embodiments may have different values. It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once a certain item is defined in an accompanying drawing, it does not need to be further discussed in subsequent drawings.

[0030] like Figure 1 As shown, according to a specific embodiment of the present invention, a complex model branch merging method based on an optimal common ancestor is provided, the method comprising:

[0031] S1, build a version tree based on the information change history of each version. Each node in the version tree corresponds to each submitted version. The parent node and child node corresponding to two versions with a parent-child relationship in the information change history are connected by a line, and the line points from the child node to the parent node. The nodes, lines and the directions of the lines constitute multiple branches of the version tree;

[0032] S2, define the two versions to be merged as the source version and the target version. When merging the source version to the target version, determine whether the two versions have a common ancestor based on the path relationship between the source version and the target version on the version tree. If yes, go to S3, if not, go to S4;

[0033] S3, selecting the best common ancestor from all common ancestors, respectively calculating the first change data between the source version and the best common ancestor and the second change data between the target version and the best common ancestor, merging the first change data and the second change data with the best common ancestor to obtain a merged version of the source version and the target version;

[0034] S4, calculating the third change data between the source version and the target version, and merging the third change data with the target version to obtain a merged version of the source version and the target version.

[0035] That is to say, in a complex model version control system, the version tree is composed of nodes and lines connecting the nodes, so as to visualize the submission history of the complex model. Among them, the node is the core element of the version tree. Each node represents a submission and version upgrade, usually containing author information, timestamp, submission message and other information. The lines in the version tree represent the relationship between the submitted versions, usually the parent-child relationship. In a complex model version control system, the lines are usually directional, from the node (child node) corresponding to the submitted version to its parent node. When a submission is merged from two versions, there are usually two lines pointing to the parent node.

[0036] Please refer to Figure 3 The complex system version tree, each number represents a node corresponding to a submitted version, and the arrows indicate the order between submitted versions, from child nodes to parent nodes. The master tag indicates that the head node of the current master branch is #7, and the feature tag indicates that the head node of the current feature branch is #6. Node #7 represents a merge commit, which merges the changes on the feature branch (represented by node #6) into the master branch (the most recent commit is node #4). The version tree can clearly describe the version history operations and also facilitate version control operations such as branch merges.

[0037] By using this configuration method, a complex model branch merging method based on the best common ancestor is provided. The method firstly constructs a version tree with the help of graph theory knowledge, significantly improves the system's ability to express and process complex version relationships, and gives it higher flexibility and accuracy; secondly, the path selection-based method provides preset rules and processes for judging the existence of common ancestors and locating the best common ancestor. Based on this rule and process, when there is no common ancestor, repeated conflict calculations can be avoided according to the branches and versions to be merged, and the best common ancestor can be reasonably determined when there is a common ancestor. Thus, the change information can be accurately identified and calculated, and the number of submissions between the best common ancestor and the source version and the target version can be minimized, effectively reducing the complexity of the change data and the potential conflict possibility, reducing manual conflict processing, and providing a guarantee for the stability of the branch merging method, thereby ensuring the accuracy, efficiency, consistency and traceability of the change data, significantly improving the stability of the version control system and user experience, and ensuring the stability and reliability of the version control system during multi-user collaboration. This method breaks through the limitation that the traditional method is only applicable to linear text files. By decomposing complex models into structures, behaviors, relationships, attributes, etc., and calculating changes based on the best common ancestor, it can achieve comprehensive version control of various model data. Compared with the prior art, the technical solution of the present invention can solve the technical problem that the branch merging method in the prior art has potential conflict processing and is not suitable for multiple branch merging of complex models.

[0038] With the increasing expansion of version iteration and modeling team, complex models may experience multiple branch merges to form an extremely complex version tree, and the probability of data anomalies caused during the branch merge process is greatly increased. Therefore, in the complex model version control system, the process of determining the ancestor version is crucial for the branch merge method. Reasonable ancestor positioning can effectively reduce the complexity of different branches relative to the optimal common ancestor version change set, reduce the conflict calculation and processing of the version control system, and provide guarantees for the consistency and integrity of the complex model. In an embodiment of the present invention, it is determined whether the two versions have a common ancestor according to the path relationship between the source version and the target version on the version tree, specifically including: determining whether the branch path of the source version on the version tree passes through the branch path of the target version on the version tree, if yes, then determining that the source version and the target version do not have a common ancestor (common node), if not, then determining that the source version and the target version have a common ancestor. Through this existence judgment rule, the situation where the branch path of the source target passes through the target version is judged as the absence of a common ancestor, which can avoid the repeated conflict calculations that may occur in the traditional method, and effectively improve the reliability of the complex model merge operation.

[0039] Furthermore, in an embodiment of the present invention, the shortest path selection principle is followed to determine the optimal common ancestor. Specifically, selecting the optimal common ancestor from all common ancestors includes: calculating the sum of the path lengths of each common ancestor to the source version and the target version respectively; and taking the common ancestor with the smallest sum of path lengths as the optimal common ancestor, that is, taking the common ancestor with the shortest path as the optimal common ancestor.

[0040] In actual applications, there may be a situation where the sum of path lengths is the smallest. To solve this problem, in an embodiment of the present invention, the configuration of using the common ancestor with the smallest sum of path lengths as the optimal common ancestor includes: when there are two or more path lengths with the same sum and the smallest sum, the common ancestor corresponding to the sum of path lengths with the latest version is selected as the optimal common ancestor. If the versions are numbered from small to large in the order of the time when the version update is submitted, the larger numbered version of the two or more common ancestors with the smallest sum of path lengths is selected as the optimal common ancestor.

[0041] Please refer to Figure 2That is to say, the source branch path of the source version and the target branch path of the target version are obtained from the established version tree respectively. If the source branch path passes through the target version, it indicates that there is no substantial common ancestor in this merge operation, avoiding misleading merge change calculations in the future. If the source branch path does not pass through the target version, the sum of the paths from each public node to the source version and the target version is further calculated, and the public node with the shortest path is taken as the optimal common ancestor. If there are multiple public nodes with the shortest paths, the node with the larger corresponding version number is taken as the optimal common ancestor. The above optimal common ancestor judgment and positioning method based on graph theory and path selection provides preset rules and processes for locating the optimal common ancestor. Based on this rule and process, the optimal common ancestor can be reasonably determined according to the branches and versions to be merged, and the number of submissions between the optimal common ancestor and the source version and the target version can be minimized, effectively reducing the complexity of the change data and the potential conflict possibility, reducing manual conflict processing, and providing guarantees for the stability of the branch merge method, thereby ensuring the accuracy, efficiency, consistency and traceability of the change data, and significantly improving the stability of the version control system and user experience.

[0042] Furthermore, in the complex model version control branch merge operation, calculating the change data is an important step to understand the evolution of the complex model. Calculating the change data includes calculating the structural changes, behavior changes, relationship changes, attribute changes, and graphic changes between two different complex model versions. The change status includes addition, deletion, and modification. In other words, the first change data, the second change data, and the third change data all include structural change data, behavior change data, relationship change data, attribute change data, and graphic change data.

[0043] After the calculation of the change data is completed, the branch merge method needs to resolve conflicts in the change data and submit it to the target branch to generate a new version. Specifically, in an embodiment of the present invention, merging the first change data and the second change data with the best common ancestor to obtain a merged version of the source version and the target version includes: determining whether there is a conflict between the first change data and the second change data, if not, applying both the first change data and the second change data to the best common ancestor to obtain a merged version of the source version and the target version, if yes, the user makes a decision on the conflicting change data in the first change data and the second change data to obtain the changed data after the decision, and applying the changed data after the decision to the best common ancestor to obtain a merged version of the source version and the target version.

[0044] Furthermore, in the embodiment of the present invention, merging the third change data with the target version to obtain a merged version of the source version and the target version includes: applying the third change data to the target version to obtain a merged version of the source version and the target version.

[0045] That is, for a branch merge with a best common ancestor, first compare the change data diff between the source version and the best common ancestor s The change data diff between the target version and the best common ancestor t , if diff s with diff t If there is no conflicting change, the final change data is diff = diff s +diff t If diff s with diff t If the changes between the two branches are contradictory, the contradictory changes need to be displayed to the user, who makes the decision and generates the final change data diff. The final change data diff is applied to the best common ancestor to obtain the merged version data. After the changes are submitted to generate a new version, the branch merge is completed. For branch merges without an actual common ancestor, the change data between the source version and the target version is directly applied to the target version to complete the final version submission.

[0046] In order to further understand the present invention, the following Figure 4 The method for locating the optimal common ancestor of the present invention is described in detail.

[0047] like Figure 4 As shown, four branch merges are performed in sequence, and the optimal common ancestor positioning process for each merge is:

[0048] First merge: The target version of this merge is #2, the source version is #3, and the best common ancestor is #1. According to rule 1, the source branch path (#3->#1) does not pass through target version #2, so there is a common ancestor. According to rule 2, the source branch path (#3->#1) and the target branch path (#2->#1) have only one common ancestor, version #1, so the best common ancestor of the first merge can be determined to be version #1.

[0049] Second merge: The target version of this merge is #3, the source version is #2, and the best common ancestor is #1. According to rule 1, the source branch path (#2->#1) does not pass through target version #3, so there is a common ancestor. According to rule 2, the source branch path (#2->#1) and the target branch path (#3->#1) have only one common ancestor, version #1, so the best common ancestor of the second merge can be determined to be version #1.

[0050] The third merge: The target version of this merge is #4, the source version is #5, and the best common ancestor is #3. According to rule 1, there are two source branch paths (#5->#3->#1) and (#5->#2->#1), neither of which passes through the target version #4, so there is a common ancestor. The two source branch paths and the two target branch paths (#4->#3->#1) and (#4->#2->#1) contain three common ancestors #3, #2, and #1. The sum of the paths to the source version and the target version is 2, 2, and 4 respectively. According to rule 2, the best common ancestor is generated in #3 and #2. According to rule 3, the version #3 with the larger version number is taken as the best common ancestor.

[0051] The fourth merge: The target version of this merge is #5, the source version is #7, and there is no common ancestor. According to rule 1, there are four source branch paths, namely (#7->#6->#4->#2->#1), (#7->#6->#4->#3->#1), (#7->#5->#4->#2->#1), (#7->#5->#4->#3->#1), which shows that there is a source branch path passing through the target version #5, so this merge actually has no common ancestor.

[0052] In summary, the present invention provides a complex model branch merging method based on the best common ancestor. The method first constructs a version tree with the help of graph theory knowledge, significantly improves the system's ability to express and process complex version relationships, and gives it higher flexibility and accuracy; secondly, the path selection-based method provides preset rules and processes for judging the existence of common ancestors and locating the best common ancestor. Based on this rule and process, when there is no common ancestor, repeated conflict calculations can be avoided according to the branches and versions to be merged, and the best common ancestor can be reasonably determined when there is a common ancestor, so that the change information can be accurately identified and calculated, and the number of submissions between the best common ancestor and the source version and the target version can be minimized, effectively reducing the complexity and potential conflicts of the change data, reducing manual conflict processing, and providing a guarantee for the stability of the branch merging method, thereby ensuring the accuracy, efficiency, consistency and traceability of the change data, significantly improving the stability of the version control system and user experience, and ensuring the stability and reliability of the version control system during multi-user collaboration. This method breaks through the limitation that the traditional method is only applicable to linear text files. By decomposing complex models into structures, behaviors, relationships, attributes, etc., and calculating changes based on the best common ancestor, it can achieve comprehensive version control of various model data. Compared with the prior art, the technical solution of the present invention can solve the technical problem that the branch merging method in the prior art has potential conflict processing and is not suitable for multiple branch merging of complex models.

[0053] For ease of description, spatially relative terms such as "above", "above", "on the upper surface of", "above", etc. may be used here to describe the spatial positional relationship between a device or feature and other devices or features as shown in the figure. It should be understood that spatially relative terms are intended to include different orientations of the device in use or operation in addition to the orientation described in the figure. For example, if the device in the accompanying drawings is inverted, the device described as "above other devices or structures" or "above other devices or structures" will be positioned as "below other devices or structures" or "below other devices or structures". Thus, the exemplary term "above" can include both "above" and "below". The device can also be positioned in other different ways (rotated 90 degrees or in other orientations), and the spatially relative descriptions used here are interpreted accordingly.

[0054] In addition, it should be noted that the use of terms such as "first" and "second" to limit components is only for the convenience of distinguishing the corresponding components. If not otherwise stated, the above terms have no special meaning and therefore cannot be understood as limiting the scope of protection of the present invention.

[0055] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A complex model branch merging method based on optimal common ancestor, characterized in that: The method comprises: S1, constructing a version tree according to the information change history of each version, wherein each node in the version tree corresponds to each submitted version, and the parent node and the child node corresponding to two versions whose information change history is a parent-child relationship are connected by a line, and the line points from the child node to the parent node, and the nodes, the lines and the directions of the lines constitute multiple branches of the version tree; S2, define two versions to be merged as a source version and a target version. When merging the source version into the target version, determine whether the two versions have a common ancestor based on the path relationship between the source version and the target version on the version tree. If yes, go to S3; if not, go to S4. S3, selecting an optimal common ancestor from all common ancestors, respectively calculating first change data between the source version and the optimal common ancestor and second change data between the target version and the optimal common ancestor, merging the first change data and the second change data with the optimal common ancestor to obtain a merged version of the source version and the target version; S4, calculating third change data between the source version and the target version, and merging the third change data with the target version to obtain a merged version of the source version and the target version.

2. The method according to claim 1, characterized in that Judging whether two versions have a common ancestor according to the path relationship between the source version and the target version on the version tree includes: Determine whether the branch path of the source version on the version tree passes through the branch path of the target version on the version tree. If so, determine that the source version and the target version do not have a common ancestor. If not, determine that the source version and the target version do have a common ancestor.

3. The method according to claim 2, characterized in that The best common ancestor selected from all common ancestors includes: Calculate the sum of the path lengths from each common ancestor to the source version and the target version respectively; The common ancestor with the smallest sum of path lengths is taken as the optimal common ancestor.

4. The method according to claim 3, characterized in that The common ancestor with the smallest sum of path lengths is considered the optimal common ancestor, including: When there are two or more paths whose sum of lengths is the same and the smallest, the common ancestor corresponding to the sum of lengths of the paths with the latest version is selected as the optimal common ancestor.

5. The method according to claim 1, characterized in that Merging the first change data and the second change data with the best common ancestor to obtain a merged version of the source version and the target version includes: Determine whether there is a conflict between the first change data and the second change data; if not, apply both the first change data and the second change data to the optimal common ancestor to obtain a merged version of the source version and the target version; if yes, the user makes a decision on the conflicting change data between the first change data and the second change data to obtain the changed data after the decision is made, and apply the changed data after the decision is made to the optimal common ancestor to obtain a merged version of the source version and the target version.

6. The method according to claim 5, characterized in that Merging the third change data with the target version to obtain a merged version of the source version and the target version includes: applying the third change data to the target version to obtain a merged version of the source version and the target version.

7. The method according to any one of claims 1 to 6, characterized in that The first change data, the second change data and the third change data all include structure change data, behavior change data, relationship change data, attribute change data and graphic change data.

Images