变更集冲突变基的制作方法

1.本公开一般地涉及基础设施建模，并且更具体地涉及用于解决基础设施建模软件架构中的冲突检测和合并中的问题的技术。


背景技术：

2.在基础设施（例如，建筑物、工厂、道路、铁路、桥梁、电气和通信网络等）的整个设计、建设和运营中，通常合期望的是使用基础设施建模软件对基础设施进行建模。一些基础设施建模软件架构涉及由用户操作的多个客户端软件应用程序（或简称“客户端”），这些应用程序与管理维护共享基础设施模型的储存库的远程（例如，基于云的）软件交互。通常合期望的是允许多个客户端在基础设施模型上同时运行，以允许用户团队并行工作。通常，需要并发策略以允许客户端协调它们的工作。一种合期望的并发策略是乐观并发策略。乐观并发策略可以允许客户端在不获得锁的情况下修改基础设施模型，然后稍后将它们的变更与其他客户端所做的变更合并，从而解决在合并时检测到的任何冲突。
3.然而，使用乐观并发策略以及稍后的冲突检测和合并可能会在基础设施建模软件架构中引入许多问题。如下文更详细地解释的，一个特定问题涉及创建不完整的时间线（即用于表示基础设施模型的有序变更集的集合）。可能会创建不示出某些冲突已经解决的不完整时间线，这可能导致正在进行新变更的另一个客户端检测已解决的冲突，但反过来。可能会出现其中客户端相互竞争和“对抗”以调和冲突的情况，从而使基础设施建模软件架构在很大程度上失去功能。
4.因此，需要改进的技术来解决基础设施建模软件架构中的冲突检测和合并中的问题。


技术实现要素：

5.在示例实施例中，提供了在基础设施建模软件架构中执行冲突检测和合并时实现变更集冲突变基的技术。变更集冲突变基涉及调整本地变更集中的变更前值，以便它们匹配远程版本而不是原始基本版本的变更后值，或者完全从本地变更集中移除变更。
6.在一个示例实施例中，在客户端设备上执行的客户端变更基础设施模型的对象的属性以创建本地版本。响应于接收到用于将属性的本地版本推送到维护基础设施模型的共享时间线的储存库的触发，客户端拉取属性的远程版本。客户端检测到远程版本和本地版本之间的冲突，并调和冲突以创建更新的本地版本。为更新的本地版本生成本地变更集。然后，客户端通过调整本地变更集中的变更前值以匹配远程版本的变更后值或从本地变更集中移除变更来对生成的本地变更集进行变基。最后，变基的本地变更集从客户端推送到储存库。
7.应当理解，除了本发明内容中讨论的那些之外，可以实现多种附加特征和替代实施例。本发明内容旨在简单地作为对读者的简要介绍，并且不指示或暗示本文提及的示例涵盖本公开的所有方面，或者是本公开的必需或必要方面。
附图说明
8.以下描述参考了示例实施例的附图，其中：图1是示例基础设施建模软件架构的至少一部分的高级框图；图2是可以由基础设施建模软件架构的客户端实现以变更对象的属性并检测和合并冲突的示例操作的流程图；图3是可以由基础设施建模软件架构的客户端实现以变更对象的属性并检测和合并冲突的示例操作的流程图，其中添加了变更集冲突变基操作；图4是一个表，示出了可能发生冲突和调和决策的变更的不同组合，以及如何通过变更集冲突变基来解决这些情况；图5a是根据第一示例的示出基本版本的存储的储存库中维护的元素表的一部分；图5b是基础设施模型的共享时间线的一部分，示出了初始时间的状态；图5c是元素表的第一客户端的本地副本的一部分，示出了第一客户端对属性值的变更；图5d是基础设施模型的第一客户端的本地时间线的一部分，示出了本地变更集的创建；图5e是元素表的第二客户端的本地副本的一部分，示出了第二客户端对属性值的变更；图5f是基础设施模型的第二客户端的本地时间线的一部分，示出了本地变更集的创建；图5g是基础设施模型的共享时间线的一部分，示出第一客户端的变更集变成新的顶端（tip）；图5h是来自第二客户端在将其本地版本推送回之前拉取和合并的基础设施模型的共享时间线的变更集；图5i是第二客户端的本地时间线的一部分，示出了第二客户端通过保持其本地变更来调和冲突；图5j是基础设施模型的共享时间线的一部分，示出了第二客户端推送其本地变更集而不变基的效果；图5k是基础设施模型的第二客户端的本地时间线的一部分，示出了变更集冲突变基的效果；图5l是基础设施模型的共享时间线的一部分，示出了第二客户端推送其变基的本地变更集的效果；图6a是根据第二示例的元素表的第二客户端的本地副本的一部分，示出了设置为拉取的变更集的属性值的属性值；图6b是基础设施模型的第二客户端的本地时间线的一部分，示出了合并操作与对拉取的变更集的接受的结果；图6c是基础设施模型的第二客户端的本地时间线的一部分，示出了变更集冲突变基的效果；图7a是根据第三示例的在储存库140
‑
144中维护的元素表的一部分，示出了基础设施模型的基本版本的存储；
图7b是基础设施模型的共享时间线的一部分，示出了初始时间的状态；图7c是基础设施模型的第一客户端的本地时间线的一部分，示出了本地变更集的创建；图7d是基础设施模型的第二客户端的本地时间线的一部分，示出了本地变更集的创建；图7e是基础设施模型的共享时间线的一部分，示出第一客户端的变更集变成新的顶端；图7f是基础设施模型的第二客户端的本地时间线的一部分，示出了第二客户端通过保持本地变更来调和冲突；和图7g是基础设施模型的第二客户端的本地时间线的一部分，示出了变更集冲突变基的效果。
具体实施方式
9.定义如本文所使用的，术语“基础设施”是指在现实世界中已经构建或计划构建的物理结构或对象。基础设施的示例包括建筑物、工厂、道路、铁路、桥、电力和通信网络等。
10.如本文所使用的，术语“构建的基础设施模式（schema）”或“bis”是指一种类型的概念模式（即，概念数据模型），其描述了表示基础设施的数据的语义。
11.如本文所使用的，术语“基础设施模型”是指基础设施的数字表示。基础设施模型可以根据构建的基础设施模式来组织。一种特定类型的基础设施模型可以是imodel
®
基础设施模型。
12.如本文所使用的，术语“基础设施建模储存库”，或简称为“储存库”，是指存储一个或多个基础设施模型的分布式数据库。这样的分布式数据库的每个组成数据库可以被称为“公文包（briefcase）”，如下面讨论的。
13.如本文所使用的，术语“变更集”是指捕获将数据库的特定实例从一个版本变换到新版本所需的变更的持久电子记录。如下面解释的，在示例实现中，有序系列的变更集可以表示时间线。时间线的变更集可以捕获将数据库实例从一个版本（版本m）移动到另一个版本（版本q）所需的变更。变更集可以按顺序的次序被应用，以便将版本m移动到版本q。变更集也可以按相反顺序的次序被应用，以便将版本q移动回到版本m。
14.如本文所使用的，术语“公文包”是指数据库的特定实例。在示例实现中，当公文包用作储存库的组成数据库时，公文包可以表示储存库的特定版本的信息的物化视图。公文包的一个版本（版本m）可以被认为是将所有变更集（直到并且包括变更集m）顺序应用到“基线”公文包（例如，空的“基线”公文包）所产生的信息。通过向它应用从n到q（包括n和q）的变更集的集合，版本m的公文包可以被移动到另一个版本（版本q）。
15.如本文所使用的，术语“元素”是指维持在公文包中的记录。一个元素表示（即，“模型”，在该术语的口语意义上）现实世界中的实体。在示例实现中，现实世界中的实体可以是基础设施的单个单元。
16.如本文所使用的，术语“模型”是指一组元素的容器，其中该组元素共同表示（即，“模型”，在该术语的口语意义上）现实世界中的实体。在示例实现中，现实世界中的实体可
以是基础设施的单个单元。在一些情况下，模型可以嵌套。也就是说，模型被称为将特定元素“分解”成更细化粒度的描述（即，描述现实世界中相同实体但在细化粒度下的描述）。
17.如本文所使用的，术语“关系”是指涉及两个或更多个元素或模型的连接。关系的示例包括可能暗示所有权的父子关系和可能定义组的对等关系。
18.如本文所使用的，术语“数字对象”或简称为“对象”统称为元素、模型或关系。对象可能已由具有值的一组属性定义。
19.示例实施例图1是示例基础设施建模软件架构的至少一部分的高级框图。该架构可以划分为在一个多个或多个本地布置的计算设备（统称为“客户端设备”）上执行的客户端软件110，以及在可通过互联网访问的一个或多个远程计算设备（“云计算设备”）上执行的基于云的服务软件120。
20.客户端软件110可以包括由用户操作的客户端软件应用程序（或简称为“客户端”）120。客户端120可以具有各种类型，包括直接在客户端设备的操作系统下操作的桌面型客户端和在网络浏览器内操作的基于网络的客户端应用程序。客户端120可能主要关注提供允许用户创建、修改、显示和/或以其他方式与基础设施模型（例如imodel
®
基础设施模型）交互的用户界面。基于云的软件112可以包括管理维护基础设施模型的储存库140
‑
144的基础设施建模中枢服务（例如，imodelhub
tm
服务）130。客户端120和基础设施建模中枢服务130可以利用构建的基础设施模式（bis），其使用高级数据结构和概念来描述表示基础设施的数据的语义。因此，客户端120和基础设施建模中枢服务130可被称为“基于bis”的软件。基于bis的软件可以利用（分层）底层数据库系统（例如，sqlite）132，其处理原始数据库操作，例如底层分布式数据库（例如，sqlite数据库）的表的行的插入、更新和删除。数据库系统132可以利用描述表的实际行和列的底层数据库模式（例如，sqlite模式）。
21.更详细地，概念模式（例如bis）可以使用包括元素、模型和关系的数字对象（或简称“对象”）来描述基础设施，所述数字对象用作基础设施模型的构建块。元素表示（即，“模型”，在该术语的口语意义上）现实世界中的实体。基于被建模实体的性质，一个元素可以是“领导”元素。其他元素通常与领导元素反向相关。模型充当元素集合的容器，其中该元素集合共同表示（即，“模型”，在该术语的口语意义上）现实世界中的实体。在一些情况下，模型可以嵌套。也就是说，模型被称为将特定元素“分解”成更细化粒度的描述。模型可以根据模型层次结构进行布置，以支持从多个角度进行建模。单个储存库模型可以用作模型层次结构的根。关系涉及两个或更多个元素或模型。关系的示例包括可以暗示所有权的父子关系和可以定义组的对等关系。
22.同样地，底层数据库模式（例如sqlite模式）可以描述对象如何被存储到底层数据库的表的各个行。可以使用存储对象属性的多个不同表的多个行来维护所述对象。例如，元素的属性可以跨多个表的多个行散布。为了创建、移除或修改对象，由底层数据库系统（例如sqlite）132在适当的表的适当行上执行原始的数据库操作，诸如插入、删除或更新。
23.为了实现多个版本和并发操作，客户端120和基础设施建模中枢服务130可以利用公文包和变更集。公文包是数据库的特定实例，其当用作储存库140
‑
144的组成数据库时，表示储存库的特定版本的信息的物化视图。最初可以以编程方式创建“空”基线公文包。随着时间的推移，基线公文包可能会用变更集进行修改，所述变更集是捕获将特定实例从一
个版本转换为新版本所需的变更的持久电子记录。变更集通常包括对象选择属性的原始值（变更前）值以及那些选择属性的新（变更）值。
24.每个变更集都是在基础设施模型的使用期中的某个点做出的。基础设施模型的使用期可以表示为一个或多个时间线。通常有主时间线和分支时间线，其中每个分支时间线代表替代版本的开发。通常，每个变更集都记录了立即进行的变更集的唯一标识，其通常称为它的“父变更集”或简称为“父辈”。时间线中的最新变更集通常称为“顶端变更集”或简称为“顶端”。基础设施模型的“顶端状态”反映了直到顶端的变更集的应用。向时间线添加变更集（从而使其成为顶端）通常被称为“推送”。虽然可能有多个时间线（例如，主要和分支），但为了下面的描述简单，假设只有一个时间线。应该理解，下面讨论的技术可以很容易地扩展到与多个时间线一起使用。
25.随着时间线中变更集数量的增长，获取基线公文包并应用将其转换为特定版本需要的所有变更集所需的时间可能变大。出于这个原因，通常生成附加的公文包，所述附加的公文包在沿着时间线的不同点存储基础设施模型的不同版本。每个附加的公文包都可以被视为不同时间点基础设施模型的“快照”。为了达到基础设施模型的顶端状态，可以访问最近的公文包并应用直到并包括顶端的变更集。
26.基础设施建模中枢服务130可以在储存库140
‑
144中维护公文包150和一组接受的变更集160（即，已经成功推送的变更集）。当客户端120期望对基础设施模型进行操作时，它可以从最接近期望状态（例如，顶端状态）的储存库140
‑
144获得公文包150，并从在应用时把所述公文包带到期望状态的储存库140
‑
144获得那些接受的变更集160。为了避免不断访问储存库140
‑
144的需要，客户端可以维护本地副本152（数据库的本地实例）的副本。
27.当客户端120希望对基础设施模型进行变更时，它可以使用数据库系统（例如，sqlite）132在其本地副本的表的行上执行原始数据库操作，诸如插入、更新和删除。客户端120记录这些原始数据库操作并最终将它们捆绑以创建本地变更集162。在此阶段，本地变更集162表示对基础设施模型的未决变更，其本地地反映在客户端120上本地，但尚未被接受与其他客户端共享。随后，客户端120可以将本地变更集162推送回到基础设施模型中枢服务130以被添加到储存库140
‑
144中的一组接受变更集160。以此方式，扩展了基础设施模型的共享时间线。
28.由于共享时间线通常由独立操作的多个客户端120构建，因此存在变更发生冲突的可能性。当两个变更不能两者都应用（以任何次序）而不相互矛盾或颠倒时，它们发生冲突。当多个客户端插入同一对象的属性时，冲突变更一般不发生，但是当多个客户端将同一对象的同一属性变更为不同值时，或者当一个客户端删除另一个客户端变更的对象时，冲突变更可能发生，或者反之亦然。因此，需要一个并发策略来允许客户端协调它们的工作。
29.客户端120可以实现乐观并发策略。作为这些操作的部分，客户端检测并合并本地变更集162的变更与在客户端处理其变更期间由其他客户端推送的接受的变更集150的变更之间的冲突。
30.图2是可以由基础设施建模软件架构的客户端120实现以变更对象的属性并检测和合并冲突的示例操作的流程图。出于讨论的目的，考虑了基础设施模型的三个版本（及其对象和它们的属性）。“基本版本”是客户端开始处理其变更之前的版本。“本地版本”是由客户端的未决变更产生的版本，如由本地变更集所反映的那样。“远程版本”是一种顶端状态，
其反映其他客户端的变更集到基本版本的应用，直到并包括最近推送的变更集。
31.在步骤210，客户端120拉取基础设施模型的基本版本。如以上所讨论的，客户端可以获得公文包150和接受的变更集160，其当应用时，将基础设施模型带到当前顶端。基本版本反映沿共享时间线的初始时间（例如，时间=0）的基础设施模型的状态。
32.在步骤220，客户端120变更基础设施模型的至少一个对象的至少一个属性，创建本地版本。例如，基础设施模型的基本版本可以显示在客户端的用户界面中，并且响应于用户界面中的用户输入，可以对其做出变更。本地版本反映沿时间线的本地分支的某一秒（例如，时间=2.1）的基础设施模型的状态。
33.作为步骤230的一部分，客户端120记录属性的基本版本以及本地版本。客户端可以利用底层数据库系统（例如，sqlite）132来记录该信息，因为在底层数据库的表的行上执行原始操作。数据库系统可以记录每个被变更的属性的唯一的、稳定的标识、其变更前值（例如，来自时间=0的值）和其变更的值（例如，来自时间=2.1的值）。
34.在步骤240，客户端120尝试将属性的本地版本推送到储存库140
‑
144以扩展共享时间线。尝试推送的触发可以是客户端120的用户界面中的用户输入，或者另一类型的事件。推送的尝试可能被基础设施模型中枢服务130拒绝，例如，因为共享时间线在其他客户端期间被扩展。在这种情况下，本地变更可能需要与附加的变更集进行调和，然后才能将它们添加到时间线。
35.在步骤250，客户端120拉取属性的远程版本，该版本反映在客户端120在基础设施模型上工作的期间（例如，在时间=0和时间=2.1之间）由其他客户端做出的变更。客户端120通过从储存库140
‑
144拉取直到当前顶端的变更集来获得远程版本。例如，变更集可能已由第二客户端推送（例如，在时间=1.1），其中包括对本地变更的相同属性的不同变更。现在，第二客户端可以拉取此类变更集以了解这些变更。
36.在步骤260，客户端120检测到属性的远程版本和属性的本地版本之间的冲突。客户端可以将拉取的变更集的值与本地值进行比较，并确定为相同的属性分配了不同值的地方。例如，将拉取的变更集的标识和值（例如，来自时间=1.1）与本地版本的变更值（例如，在时间=2.1）进行比较。
37.在步骤270，客户端120调和属性的本地版本和远程版本之间的冲突。例如，调和拉取的变更集（例如，来自时间=1.1）与本地变更（例如，在时间=2.1） 之间的冲突。可以通过拒绝远程变更以支持保留本地变更（或生成新的本地变更）或通过反转和替换本地变更来接受远程变更来调和冲突。使用远程变更还是本地变更的决策可以基于用户输入。例如，客户端可以在其用户界面中显示冲突的指示，并且用户可以选择要利用哪个变更。
38.在步骤280，为更新的本地版本生成本地变更集162。本地变更集存储来自基本版本的原始值（变更前值）以及更新的本地版本的新值（变更的值）。
39.在步骤290，推送本地版本。客户端120将本地变更集162上传到储存库140
‑
144，在那里它被添加到接受的变更集160，用新的顶端更新时间线。新接受的变更集将指示变更的值（例如，时间=2.1的）替换了来自基本版本中的值（例如，时间=0的）。基础设施模型的新顶端状态（包括新接受的变更集）可以被其他客户端访问，其中新顶端被拉取。其他客户端也可以利用基础设施模型的新顶端状态来推送它们自己的变更，用于显示目的或用于其他任务。
40.不幸的是，这里可能会出现问题，因为由图2中的步骤序列产生的时间线没有示出与其他客户端（例如，第二客户端）的冲突已经解决（即时间线是不完整的）。推送的本地版本似乎是基于基本版本，而不是基于远程版本。即，推送的本地变更集162（例如，来自时间=2.1）似乎已经基于基础设施模型的原始状态（例如，在时间=0）。没有迹象表明客户端知道并调和了其他客户端的任何变更集（例如，在时间=1.1时的变更下，第二客户端的拉取的变更集）。因此，时间线是不完整的。
41.不完整的时间线可能会导致另一个客户端（例如，第二客户端）其对基础设施模型进行新的变更以检测已经解决的冲突，但反过来。可能会出现客户端相互竞争和“对抗”以调和冲突的情况，导致基础设施建模软件在很大程度上失去功能。
42.为了解决这个问题，可以向图2的步骤序列中引入变更集冲突变基。变更集冲突变基涉及调整本地变更集162中的变更前值，以便它们匹配远程版本（当前顶端）而不是原始的基本版本的变更后值，或者完全从本地变更集中移除变更。一旦本地变更集中的所有冲突变更都已变基（调整变更前值或完全移除变更，视情况而定），则本地变更集可能会被推送以变成新的顶端。从储存库140
‑
144拉取变基的变更集的其他客户端将不会看到任何未解决的冲突。它们看到的时间线是完整的，具有与先前状态匹配的属性的任何变更前值。
43.图3是可以由基础设施建模软件架构的客户端120实现以变更对象的属性并检测和合并冲突的示例操作的流程图，其中添加了变更集冲突变基操作。步骤310
‑
360分别与图2的步骤210
‑
260相同。然而，步骤370是从步骤270修改而来的，在步骤370中，客户端120调和属性的本地版本与远程版本之间的冲突，其包括子步骤365。在子步骤375中，底层数据库系统（例如，sqlite）132创建存储关于远程版本的变更后值和/或是否要完全移除本地变更的信息的变基记录。此外，步骤380是从步骤280修改而来的，其中客户端120生成本地变更集162，以包括子步骤385。在子步骤385中，客户端使用底层数据库系统（例如，sqlite）132来访问先前的存储的变基记录，并应用它们来调整变更前值，以便它们匹配远程版本（当前顶端）的变更后值或完全移除变更。该序列在步骤390结束，该步骤再次与图2的步骤290相同。
44.图3的子步骤375和385中的变更集冲突变基操作可以涵盖由可能发生冲突的变更类型的不同组合引起的各种情况，以及可以调和那些冲突的方式。图4是一个表，示出了可能发生冲突的变更的不同组合和调和决策，以及如何通过变更集冲突变基来解决这些情况。如行410中所示，在本地变更是更新并且远程变更是更新，并且通过拒绝远程变更以支持保留本地变更来调和冲突的情况下，变更集冲突变基调整了本地版本中的变更前值以匹配远程版本的变更后值。在这种情况下，本地变更集中的变更前值变更为拉取的变更集中的变更后值。如行420、440和470中所示，在本地变更是更新并且远程变更是更新，并且通过接受远程变更而不是本地变更来调和冲突的情况下；或者本地变更是更新并且远程变更是删除，并且通过接受远程变更而不是本地变更来调和冲突；或者在本地变更是删除并且远程变更是删除，并且通过接受远程变更而不是本地变更的来调和冲突的情况下，变更集冲突变基完全移除本地变更。在这些情况下，本地变更被从本地变更集中完全删除。
45.应该注意的是，变更集冲突变基可能不完全支持某些情况。如行430和行460中所示，在本地变更是更新并且远程变更是删除，并且通过拒绝远程变更以支持保留本地变更来调和冲突的情况下；或者在本地变更是删除并且远程变更是更新，并且通过接受远程变
更而不是本地变更来调和冲突的情况下，变更集冲突变基可能不支持该操作。拒绝与本地更新冲突的远程删除可能是不可行的，因为远程删除的范围通常比本地更新的范围更广。例如，一个对象通常是一组相关对象的部分。远程删除可能会将它们全部移除，而本地更新可能仅影响一个对象。优选地通过客户端的用户之间的通信来避免这种情况。同样地，接受对本地删除的对象的远程更新可能是不可行的。变更集中没有足够的信息来取消删除对象。再次，优选地通过客户端的用户之间的通信来避免这种情况。
46.通过考虑多个特定示例，可以更好地理解上述用于变更集冲突变基的技术。在第一示例中，假设基础设施模型包括一个对象，特别是一个元素，其是唯一标识的，特别是由elementid=1唯一标识，在初始时间，特别是时间=0，具有带有值的属性，特别是propertya=0。图5a是根据第一示例的在示出基本版本的存储的储存库140
‑
144中维护的元素表的一部分。元素表由底层数据库系统（例如sqlite）维护。应当理解，虽然在该第一示例中，存在bis级元素和底层表的单行之间的简单映射，但映射可能复杂得多。
47.图5b是基础设施模型的共享时间线的一部分，示出了初始时间（时间=0）的状态。图5b中括号内的表达式表示变更集。本示例中的基本版本首先是通过插入具有elementid=1和propertya=0的元素生成的。
48.假设两个客户端（称为“client1”的第一客户端和称为“client2”的第二客户端）拉取基础设施模型的基本版本，部分获得图5b所示的变更集。每个客户端可以存储它自己的本地副本，例如，使用本地公文包。
49.假设第一次（时间=1.1），第一客户端将elementid=1的propertya从0变更为1，从而在第一客户端创建基础设施模型的本地版本。如以上所讨论的，这种变更可以响应于第一客户端的用户界面中的用户输入。
50.图5c是元素表的第一客户端的本地副本的一部分，示出了第一客户端对属性值的变更。图5d是基础设施模型的第一客户端的本地时间线的一部分，示出了本地变更集的创建。可以看出，第一客户端的本地时间线的时间=l.l处的变更集包括对elementid=l的更新，示出propertya的旧值0和新值1。
51.假设第二次（时间=2.1）第二客户端将elementid=1的propertya从0变更为2，从而在第二客户端创建基础设施模型的本地版本。这种变更可以响应于在第二客户端的用户界面中的用户输入。图5e是元素表的第二客户端的本地副本的一部分，示出了第二客户端对属性值的变更。图5f是基础设施模型的第二客户端的本地时间线的一部分，示出了本地变更集的创建。如可以看出，第二客户端的本地时间线在时间=2.1处的变更集包括对elementid=1的更新，示出了propertya的旧值0和新值2。
52.假设触发第一客户端以将属性的本地版本推送回储存库140
‑
144，以更新共享时间线。接受变更集后，将更新共享时间线。图5g是基础设施模型共享时间线的一部分，示出第一客户端的变更集变成新的顶端。已在共享时间线中时间=l处添加变更集。
53.假设触发第二客户端以将其属性的本地版本推送回储存库140
‑
144，以更新共享时间线。第二客户端从基础设施模型开始，其中在时间=0时有一个变更集，但是现在顶端是在时间=1。所以第二个客户的副本已经过时了。第二客户端应拉取并合并在时间=l时的变更集。
54.图5h是来自基础设施模型的共享时间线的变更集，第二客户端在将其本地版本推
送回之前拉取和合并所述变更集。当尝试应用变更集时，第二客户端的数据库系统（例如sqlite）检测到冲突。第二客户端对propertya的变更基于propertya=0，而第一客户端变更了propertya=l。这表明当第二客户端进行本地变更时，第二客户端不知道时间=l时的变更集。假设第二客户端通过保持propertya=2的本地变更，拒绝第一客户端的变更来调和冲突，例如，响应其用户界面中的输入。
55.图5i是第二客户端的本地时间线的一部分，示出了第二客户端通过保持其本地变更来调和冲突。如可以看出，时间=2.1时的变更集有一个旧属性值，它与时间=l时其父辈的新属性值不一致（即old:propertya=0与new:propertya=l不一致）。如果没有变基，将出现问题。
56.图5j是基础设施模型的共享时间线的一部分，示出了第二客户端推送其本地变更集而不变基的效果。如果另一个客户端（例如，第一客户端）拉取时间=2c时的变更集，它将检测到第二客户端已解决的相同冲突，但反过来（因为旧的属性值与它的父辈的新属性值不一致）。该问题利用变更集冲突变基解决了。
57.利用变更集冲突变基，第二客户端在推送之前在时间=2.l变更了变更集，因此它基于时间=l时的变更集。图5k是基础设施模型的第二客户端的本地时间线的一部分，示出了变更集冲突变基的效果。如可以看出，时间=2.l时的变更集已被更改，因此旧属性值（即old:propertya=l）与其父辈在时间=l时的新属性值（即new:propertya=l） 一致。
58.图5l是基础设施模型的共享时间线的一部分，示出了第二客户端推送其变基的本地变更集的效果。如果另一个客户端（例如，第一客户端）拉取时间=2时的变更集，它将不会检测到冲突，因为时间=2时的变更集基于时间=l时的变更集，其中旧属性值和新属性值一致。
59.在第二示例中，假设情况与上面讨论的第一示例相同，但是为了调和冲突，第二客户端不是保持本地变更并拒绝第一客户端的变更，而是第二客户端接受第一客户端对propertya=1的变更而不是其对propertya=2的本地变更。图6a是根据第二示例的元素表的第二客户端的本地副本的一部分，示出了设置为拉取的变更集的属性值的属性值。图6b是基础设施模型的第二客户端的本地时间线的一部分，示出了合并操作的结果，其中接受了拉取的变更集。如可以看出，第二客户端的本地时间线的时间=2.l时的变更集包括对elementid=l的更新，示出了propertya的旧值0（即old:propertya=0）和新值2（new:propertya=2），其被时间=l时的变更集与对elementid=l的更新跟随并覆盖，示出了propertya的旧值0（old:propertya=0）和新值2（new:propertya=2）。一经合并，时间=l处的变更集就似乎不是基于第二客户端的本地时间线中时间=2.l时的变更集，因为旧值（old:propertya=0）与先前变更集的新值（new:propertya=2）不匹配。如果第二客户端将时间=2.l处的变更集推送到共享时间线，并且另一个客户端（例如，第一客户端）要拉取变更集，它将检测到第二客户端已解决的相同冲突，但是反过来。
60.该问题利用变更集冲突变基解决了。在这种情况下，第二客户端在推送之前移除时间=2.1时的变更集。图6c是基础设施模型的第二客户端的本地时间线的一部分，示出了变更集冲突变基的效果。如可以看出，时间=2.1处的变更集已被完全移除。由此，如果基于来自第二客户端的信息更新共享时间线，则另一个客户端将不会检测到冲突，因为新属性值和旧属性值之间没有差异。
61.在第三示例中，假设基础设施模型的基本版本包括elementid=1，在时间=0时具有propertya=0。图7a是根据第三示例的示出了基础设施模型的基本版本的存储的储存库140
‑
144中维护的元素表的一部分。图7b是基础设施模型的共享时间线的一部分，示出了初始时间（时间=0）时的状态。
62.假设，在第一次（时间=l.l），第一客户端将elementid=l的propertya从0变更到1，在第一客户端创建基础设施模型的本地版本。如以上所讨论的，这种变更可以响应于第一客户端的用户界面中的用户输入。
63.图7c是基础设施模型的第一客户端的本地时间线的一部分，示出了本地变更集的创建。如可以看出，第一客户端的本地时间线的时间=l.1时的变更集包括对elementid=l的更新，示出了propertya的旧值0和新值1。
64.假设，在第二次（时间=2.1），第二客户端删除关于元素id=1的元素，从而在第二客户端创建基础设施模型的本地版本。这种变更可以响应于在第二客户端的用户界面中的用户输入。图7d是基础设施模型的第二客户端的本地时间线的一部分，示出了本地变更集的创建。如可以看出，第二客户端处的本地时间线在时间=2.1时的变更集包括对elementid=1的删除。数据库系统（例如，sqlite）在删除元素之前维护propertya的旧值0。
65.假设触发第一客户端以将本地版本推送回储存库140
‑
144，以更新共享时间线。在接受来自第一客户端的变更集后，更新共享时间线。图7e是基础设施模型的共享时间线的一部分，示出了第一客户端的变更集变成新的顶端。变更集已在共享时间线中的时间=l时添加。
66.假设触发第二客户端以将其本地版本推送回储存库140
‑
144，以更新共享时间线。第二客户端从基础设施模型开始，其中在时间=0时有一个变更集，但现在顶端是在时间=1。所以第二个客户的副本过时了。第二客户端应拉取并合并时间=l时的变更集。
67.当第二客户端拉取变更集时，第二客户端的数据库系统（例如sqlite）检测到冲突，因为在第二客户端的本地版本中不存在elementid=l。假设第二客户端通过保持删除的本地变更并拒绝第一客户端的变更来调和冲突。图7f是基础设施模型的第二客户端的本地时间线的一部分，示出了第二客户端通过保持本地变更来调和冲突。如可以看出，时间=2.1时的变更集具有旧属性值，它与时间=l时其父辈的新属性值不一致（即old:propertya=0与new:propertya=l不一致）。如果没有变基，将出现问题。
68.利用变更集冲突变基，第二客户端在推送之前变更时间=2.l时的变更集，因此它基于时间=l时的变更集。图7g是基础设施模型的第二客户端的本地时间线的一部分，示出了变更集冲突变基的效果。如可以看出，时间=2.l时的变更集已被更改，因此旧属性值（即old:propertya=l）与其父辈在时间=1时的新属性值（即new:propertya=l）一致。现在时间线时完整的，并且其他客户端将不会检测到未解决的冲突。
69.总之，可以采用变更集冲突变基来调整本地变更集中的变更前值，以便它们匹配远程版本（当前顶端）而不是原始基本版本的变更后值，或者完全从本地变更集中移除变更，因此，一旦推送，拉取变基的变更集的其他客户端将不会看到任何未解决的冲突。这种技术可以使得能够在使用底层数据库系统（例如，sqlite）来管理原始操作的基础设施建模软件架构中使用乐观并发策略。
70.应当理解，可以对技术进行多种多样的适配和修改。此外，一般来说，功能可以用
软件、硬件或其各种组合来实现。软件实现可以包括存储在非暂时性电子设备可读介质（例如，非暂时性计算机可读介质）中的电子设备可执行指令（例如，计算机可执行指令），所述非暂时性电子设备可读介质（例如，非暂时性计算机可读介质）诸如是易失性存储器、持久存储设备或其他有形介质。硬件实现可以包括逻辑电路、专用集成电路和/或其他类型的硬件组件。此外，组合的软件/硬件实现可以包括存储在非暂时性电子设备可读介质中的电子设备可执行指令，以及一个或多个硬件组件二者。最重要的是，应当理解，以上描述意味着仅作为示例来考虑。