A complex model branch merging method based on optimal common ancestor

Abstract

The application provides a complex model branch merging method based on an optimal common ancestor, which comprises the following steps: constructing a version tree according to the information change history of each version; judging whether the source version and the target version have a common ancestor according to the path relationship of the source version and the target version on the version tree, if yes, selecting an optimal common ancestor from all the common ancestors, 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, and merging the first change data and the second change data with the optimal common ancestor to obtain a merged version; if no, calculating third change data between the source version and the target version, and merging the third change data with the target version to obtain the merged version. The technical scheme of the application is applied to solve the technical problem that the branch merging method in the prior art is not suitable for multiple branch mergings of complex models due to potential conflict processing.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of version control, and particularly relates to a complex model branch merging method based on an optimal common ancestor. BACKGROUND

[0002] With the rapid development of information technology and the popularity of multi-person collaboration mode, people's demand for complex model multi-user collaboration has significantly increased. Complex model version control is increasingly widely used in software engineering, system engineering, electronic engineering and other fields, which 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. The complexity not only comes from the large size and large number of elements, but also from the complex dependence and association relationship between elements. As the core component of complex model to realize 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 history changes of the model. With the increasing iteration of versions and the expansion of modeling teams, complex models may undergo multiple branch merging, forming a very complex version tree, and the probability of data anomalies during branch merging is greatly increased.

[0003] The key difficulty of the traditional branch merging method is the determination of the common ancestor, which mainly relies on the Three-Way Merge method. This method compares the differences between two branches to be merged and their common ancestor to perform the merging operation. However, this method often ignores the context information and version number of historical commits when finding the common ancestor of the two branches, and only mechanically merges based on the differences in the text, which cannot be applied to the multiple branch merging scenario of complex models. Its main limitations are as follows: 1) It is usually limited to linear text structure and is not suitable for complex models containing multi-layer nested structure, nonlinear relationship, specific semantic constraints, etc.; 2) It cannot accurately identify changes that have been merged in a branch, which can easily cause unnecessary repeated merging and increase the risk of merging conflicts; 3) When there are multiple common ancestors, the traditional method lacks a clear selection standard, increasing the complexity and potential errors of the merging operation. SUMMARY

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

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

[0006] S1, constructing a version tree according to an information change history of each version, each node in the version tree corresponding to a version representing each commit, the information change history connecting a parent node and a child node corresponding to two versions in a parent-child relationship through a line, and the line being pointed by the child node to the parent node, the nodes, the line and the pointing of the line constituting a plurality of branches of the version tree;

[0007] S2, defining two versions to be merged as a source version and a target version, when merging from the source version to the target version, judging whether the two versions have a common ancestor according to a path relationship of the source version and the target version on the version tree, if yes, turning to S3, if no, turning to S4;

[0008] 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, and 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;

[0009] 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.

[0010] Further, judging whether the two versions have a common ancestor according to the path relationship of the source version and the target version on the version tree comprises:

[0011] judging whether a branch path of the source version on the version tree passes through a branch path of the target version on the version tree, if yes, judging that the source version and the target version do not have a common ancestor, if no, judging that the source version and the target version have a common ancestor.

[0012] Further, selecting an optimal common ancestor from all common ancestors comprises:

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

[0014] taking the common ancestor with the smallest sum of path lengths as the optimal common ancestor.

[0015] Further, taking the common ancestor with the smallest sum of path lengths as the optimal common ancestor comprises:

[0016] when there are more than two common ancestors with the same and smallest sum of path lengths, selecting the common ancestor with the latest version as the optimal common ancestor.

[0017] Further, 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 comprises:

[0018] determining whether there is a conflict between the first change data and the second change data, if not, applying 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, and if yes, making a decision on the change data in which there is a conflict between the first change data and the second change data by a user to obtain selected change data, and applying the selected change data to the optimal common ancestor to obtain a merged version of the source version and the target version.

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

[0020] Further, the first change data, the second change data and the third change data all comprise structural change data, behavior change data, relationship change data, attribute change data and graph change data.

[0021] The technical scheme of the present application provides a complex model branch merging method based on an optimal common ancestor. The method first constructs a version tree by means of graph theory knowledge, significantly improves the expression and processing ability of the system for complex version relationships, and gives it higher flexibility and accuracy. Secondly, the method based on path selection provides preset rules and processes for common ancestor existence judgment and optimal common ancestor positioning. Based on this rule and process, when there is no common ancestor between the branches to be merged and the versions, repeated conflict calculation can be avoided, and when there is a common ancestor, the optimal common ancestor can be reasonably determined. Therefore, by accurately identifying and calculating the change information, the number of commits between the optimal common ancestor and the source version and the target version is minimized, the complexity and potential conflict possibility of the change data are effectively reduced, manual conflict processing is reduced, the stability of the branch merging method is ensured, and the accuracy, efficiency, consistency and traceability of the change data are ensured. The stability of the version control system and the user experience are significantly improved, and the stability and reliability of the version control system in multi-user collaboration are ensured. The method breaks through the limitation of traditional methods which are only applicable to linear text files. By decomposing complex models into structures, behaviors, relationships, attributes, etc., change is calculated based on the optimal common ancestor, and comprehensive version control of various types of model data can be achieved. BRIEF DESCRIPTION OF DRAWINGS

[0022] The accompanying drawings included are intended to provide a further understanding of the embodiments of the present application, and constitute a part of the specification, serve to explain the embodiments of the present application together with the text description, and illustrate the principles of the present application. Obviously, the accompanying drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort.

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

[0024] Figure 2 A positioning flow diagram of an optimal common ancestor is shown according to a specific embodiment of the present application;

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

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

[0027] It should be noted that the embodiments and features of the embodiments in the present application can be combined with each other without conflict. The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings of the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. The description of the at least one example embodiment is actually only illustrative, but not as any limitation on the present application and its application or use. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0028] It should be noted that the terms used herein are only for describing specific embodiments, and are not intended to limit the example embodiments according to the present application. As used herein, the singular form is intended to include the plural form unless the context clearly indicates otherwise, and it should also be understood that when the terms "comprise" and / or "include" are used in the specification, there is a presence of a feature, step, operation, device, component and / or combinations thereof.

[0029] The foregoing is considered as illustrative only of the principles of the application. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the application to the exact construction and practice described. Accordingly, all such variations are intended to be included within the scope of the present application as defined in the following claims, along with full equivalents thereof. It is to be understood that the phraseology and terminology employed herein are for the purpose of description and not of limitation. Any use of section headings is intended to aid reading the application and is not to be interpreted as limiting. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted in an overly literal or restricted way unless expressly so defined herein. All publications mentioned herein are incorporated by reference in their entirety for the purpose of describing and disclosing the methodologies, techniques, and procedures described therein that might be used in connection with the application. Nothing herein is to be construed as an admission that the application is not entitled to antedate such publication by virtue of prior application. All patents and publications mentioned herein are hereby incorporated by reference in their entirety for the purpose of describing and disclosing the methodologies, techniques, and procedures described therein that might be used in connection with the application. Nothing herein is to be construed as an admission that the application is not entitled to antedate such publication by virtue of prior application.

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

[0031] S1, constructing a version tree according to information change history of each version, each node in the version tree corresponds to a version representing each commit, the information change history is connected by lines between the parent node and the child node corresponding to two versions in parent-child relationship, and the lines are pointed by the child node to the parent node, the nodes, the lines and the pointing of the lines constitute multiple branches of the version tree;

[0032] S2, defining two versions to be merged as a source version and a target version, when merging from the source version to the target version, judging whether there is a common ancestor between the two versions according to the path relationship of the source version and the target version on the version tree, if yes, turning to S3, if no, turning to S4;

[0033] S3, selecting an optimal common ancestor from all common ancestors, 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, and 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;

[0034] 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.

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

[0036] Please refer to the complex system version tree as shown in Figure 3 Each number represents a node corresponding to a submitted version, and the arrow represents the order relationship between the submitted versions, pointing from the child node to the parent node. The master label indicates that the head node of the current master branch is #7, and the feature label 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 last commit is node #4). The version tree can clearly describe the version history operation and provide convenience for branch merging and other version control operations.

[0037] By applying this configuration method, a complex model branch merging method based on the optimal common ancestor is provided. The method first constructs a version tree with the help of graph theory, significantly improves the expression and processing ability of the system for complex version relationships, and gives it higher flexibility and accuracy. Secondly, the path selection-based method provides preset rules and processes for common ancestor existence judgment and optimal common ancestor positioning. Based on this rule and process, when the branches and versions to be merged do not have a common ancestor, repeated conflict calculation can be avoided, and when there is a common ancestor, the optimal common ancestor can be reasonably determined. Therefore, by accurately identifying and calculating the change information, the number of commits between the optimal common ancestor and the source version and the target version is minimized, effectively reducing the complexity and potential conflict of the change data, reducing manual conflict processing, and ensuring the stability of the branch merging method. The stability of the version control system is guaranteed, thereby ensuring the accuracy, efficiency, consistency and traceability of the change data, significantly improving the stability of the version control system and the user experience, and ensuring the stability and reliability of the version control system when multiple users collaborate. This method breaks through the limitation of traditional methods which are only applicable to linear text files. By decomposing the complex model into structure, behavior, relationship and attribute, etc., the change based on the optimal common ancestor can be calculated, and comprehensive version control of various model data can be realized. Compared with the prior art, the technical scheme of the present application can solve the technical problem that the branch merging method in the prior art has potential conflict processing, which makes it unsuitable for multiple branch merging of complex models.

[0038] With the increasing of version iteration and modeling team, the complex model can experience multiple branch merging, forming a very complex version tree, and the probability of data anomaly in the branch merging process is greatly improved. Therefore, in the complex model version control system, the process of determining the ancestor version is crucial to the branch merging method. Reasonable ancestor positioning can effectively reduce the complexity of the change set of different branches relative to the optimal common ancestor version, reduce the conflict calculation and processing of the version control system, and provide guarantee for the consistency and integrity of the complex model. In the embodiment of the present application, whether the source version and the target version have a common ancestor is judged according to the path relationship of the source version and the target version on the version tree, specifically including: judging 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, it is judged that the source version and the target version do not have a common ancestor (common node), if not, it is judged that the source version and the target version have a common ancestor. Through this existence judgment rule, the case that the branch path of the source target passes through the target version is judged as not having a common ancestor, which can avoid the repeated conflict calculation that may occur in the traditional method, and effectively improve the reliability of the complex model merging operation.

[0039] Further, in the embodiment of the present application, 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; the common ancestor with the smallest path length sum is selected as the optimal common ancestor, that is, the common ancestor with the shortest path is selected as the optimal common ancestor.

[0040] In actual application, there can be a case that the path length sum is the smallest, in order to solve this problem, in the embodiment of the present application, the common ancestor with the smallest path length sum is configured as the optimal common ancestor, which includes: when there are more than two common ancestors with the same path length sum and the smallest, the latest version in the common ancestor corresponding to the path length sum is selected as the optimal common ancestor. If each version is numbered from small to large according to the time sequence of version update submission, the version with larger number in the two or more common ancestors with the smallest path length sum is selected as the optimal common ancestor.

[0041] Please refer to Figure 2That is, 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 the target version, it indicates that there is no substantial common ancestor for this merging operation, and misleading merging change calculation is avoided. If the source branch path does not pass the target version, further calculate the sum of the paths passed by each common node to the source version and the target version, and take the common node of the shortest path as the optimal common ancestor. If there are multiple common nodes with the shortest path, take the node with the larger corresponding version number as the optimal common ancestor. The above optimal common ancestor judgment and positioning method based on graph theory and path selection provides a preset rule and process for positioning the optimal common ancestor. Based on this rule and process, the optimal common ancestor can be reasonably determined according to the branches to be merged and the versions, the number of commits between the optimal common ancestor and the source version and the target version is minimized, the complexity and potential conflict possibility of the change data are effectively reduced, manual conflict processing is reduced, the stability of the branch merging method is ensured, and thus the accuracy, efficiency, consistency and traceability of the change data are ensured, and the stability of the version control system and the user experience are significantly improved.

[0042] Further, in the complex model version control branch merging operation, calculating change data is an important step to understand the evolution of the complex model. The calculation of change data includes the calculation of structural changes, behavior changes, relationship changes, attribute changes, and graphical changes between two different complex model versions. The change state includes addition, deletion, and change. That is, the first change data, the second change data, and the third change data each include structural change data, behavior change data, relationship change data, attribute change data, and graphical change data.

[0043] After the calculation of change data is completed, the branch merging method needs to solve the conflict of the change data and commit in the target branch to produce a new version. Specifically, in the embodiment of the present application, merging the first change data and the second change data with the optimal common ancestor to obtain the merged version of the source version and the target version includes: judging whether there is a conflict between the first change data and the second change data, if not, applying the first change data and the second change data to the optimal common ancestor to obtain the merged version of the source version and the target version, if yes, making a decision on the change data with a conflict in the first change data and the second change data by the user to obtain the change data after the decision, and applying the change data after the decision to the optimal common ancestor to obtain the merged version of the source version and the target version.

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

[0045] That is, for the branch merge with the optimal common ancestor, first compare the change data diff between the source version and the optimal common ancestor s and the change data diff between the target version and the optimal common ancestor t If there is no conflicting change between diff s and diff t , the final change data is diff = diff s + diff t If the changes between diff s and diff t are contradictory, the contradictory changes need to be presented to the user for decision, and the final change data diff is generated. The final change data diff is applied to the optimal common ancestor to obtain the merged version data, and the new version is generated after the change is submitted, and the branch merge is completed. For the branch merge without the 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 have a further understanding of the present application, the positioning method of the optimal common ancestor of the present application will be described in detail below. Figure 4

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

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

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

[0050] ​The third merging: the target version of this merging is #4, the source version is #5, and the optimal common ancestor is #3. According to rule one, 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, and the sum of the paths to the source version and the target version is 2, 2 and 4, respectively. According to rule two, the optimal common ancestor is generated in #3 and #2. According to rule three, the version number of #3 is larger, and the optimal common ancestor is #3.

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

[0052] In summary, the present application provides a complex model branch merging method based on the optimal common ancestor. First, the version tree is constructed with the help of graph theory knowledge, which significantly improves the system's ability to express and process complex version relationships, and gives it higher flexibility and accuracy. Second, the path selection-based method provides preset rules and processes for common ancestor existence judgment and optimal common ancestor positioning. Based on this rule and process, the method can avoid repeated conflict calculations when the branches and versions to be merged do not have a common ancestor, and reasonably determine the optimal common ancestor when there is a common ancestor. Thus, by accurately identifying and calculating the change information, the method minimizes the number of commits between the optimal common ancestor and the source version and the target version, effectively reduces the complexity and potential conflict of the change data, reduces manual conflict processing, and ensures the stability of the branch merging method. This ensures the accuracy, efficiency, consistency and traceability of the change data, significantly improves the stability of the version control system and the user experience, and ensures the stability and reliability of the version control system when multiple users collaborate. This method breaks through the limitation of traditional methods, which are only applicable to linear text files. By decomposing complex models into structure, behavior, relationship and attribute, the method can achieve comprehensive version control of various model data based on the optimal common ancestor. Compared with the prior art, the technical scheme of the present application can solve the technical problem of the prior art that the branch merging method has potential conflict processing, which makes it unsuitable for multiple branch mergings of complex models.

[0053] For purposes of the description hereinafter, spatial or directional terms, for example, "above", "below", "upper", "lower", and the like, can be used, and relate to the device as illustrated in the figures. However, it is to be understood that no absolute or relative orientation of the device is intended or implied, unless specifically described as such. Terms concerning attachments, coupling and the like, such as "connected" and "coupled" and the like, are to be construed in accordance with their normal meanings, that is, as referring to an indirect or direct connection or coupling. Any reference to "comprising" or "containing" is to be construed as meaning "comprising or containing, but not limited to". Any reference to "comprising" or "containing" is to be construed as meaning "comprising or containing, but not limited to".

[0054] In addition, it should be pointed out that the use of the terms "first", "second" and the like, to describe various elements, is merely intended to differentiate the elements from one another, and does not connote any special order or order of precedence, unless otherwise specifically indicated. Thus, the use of the terms "first", "second" and the like, is not intended to limit the scope of the present application, and is not intended to connote any special order or order of precedence.

[0055] The preferred embodiments herein disclosed are not intended to limit or restrict the scope of the application, but merely convey the best mode contemplated by the inventors of carrying out the claimed application. Modifications can be made by those skilled in the art, which yet fall within the scope of the present application. Therefore, it is, therefore, to be understood that any variations made to the application are to be considered as being within the scope of the present application as defined by the appended claims, if any, and their equivalents.

Claims

1. A method for merging branches of complex models based on the optimal common ancestor, characterized in that, The method comprises: S1, constructing a version tree according to an information change history of each version, each node in the version tree corresponding to a version representing each commit, an information change history connecting a parent node and a child node corresponding to two versions in a parent-child relationship through a line, and the line being pointed by the child node to the parent node, the nodes, the lines and the pointing of the lines constituting multiple branches of the version tree; S2, defining two versions to be merged as a source version and a target version, when merging from the source version to the target version, judging whether there is a common ancestor between the two versions according to a path relationship of the source version and the target version on the version tree, if yes, turning to S3, if no, turning 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, and 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 of claim 1, wherein, The judgment whether there is a common ancestor between the two versions according to the path relationship of the source version and the target version on the version tree comprises: judging whether a branch path of the source version on the version tree passes through a branch path of the target version on the version tree, if yes, judging that the source version and the target version do not have a common ancestor, if no, judging that the source version and the target version have a common ancestor.

3. The method of claim 2, wherein, The selection of the optimal common ancestor from all common ancestors comprises: respectively calculating a sum of path lengths of each common ancestor to the source version and the target version; selecting a common ancestor with the smallest sum of path lengths as the optimal common ancestor.

4. The method of claim 3, wherein, The selection of the common ancestor with the smallest sum of path lengths as the optimal common ancestor comprises: when there are more than two common ancestors with the same and smallest sum of path lengths, selecting a common ancestor with the latest version as the optimal common ancestor.

5. The method of claim 1, wherein, The merging of the first change data and the second change data with the optimal common ancestor to obtain the merged version of the source version and the target version comprises: judging whether there is a conflict between the first change data and the second change data, if no, applying the first change data and the second change data to the optimal common ancestor to obtain the merged version of the source version and the target version, if yes, making a decision on change data with a conflict in the first change data and the second change data by a user to obtain selected change data, and applying the selected change data to the optimal common ancestor to obtain the merged version of the source version and the target version.

6. The method of claim 5, wherein, Merging the third change data with the target version to obtain a merged version of the source version and the target version comprises: applying the third change data to the target version to obtain the 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 each comprise structure change data, behavior change data, relationship change data, attribute change data and graph change data.

Images