Jazz SCM 使用一种优化的加锁模型。您可以在不需要显示地检出或加锁的情况下对文件进行变更。其他人还可以在他们的存储库工作区中修改相同的文件。因此，人们不得不在需要将变更集成到相同的流或存储库工作区中时解决冲突。一般地说，当文件的内容有分支时就会出现冲突，这是有相同公共原始内容的文件的两个状态，两种状态都想要在存储库工作区中被接受。通常当与其他团队成员合作时会出现冲突，但您还可以在 Jazz 中创建自己工作用的分支，试着悬挂一个变更集，然后在另一个变更集中对相同的文件做出其他的变更，然后恢复悬挂的变更集。
（您的存储库工作区） S1 -> S3 -> S4
^
|
（悬挂的） S1 -> S2
最初，您的工作区中是文件的版本 S1 您进行变更，创建了文件的版本 S2，然后悬挂变更。现在您悬挂了 S1->S2。由于您悬挂了到 S2 的变更，所以您的工作区中再次选择了版本 S1。现在对文件进行另一个变更来穿件版本 S3。现在您拥有了变更 S1->S3。恢复悬挂的变更导致了冲突，因为 Jazz 不知道选择哪个版本：S2 或者 S3？要解决冲突，您可以将 S2 和 S3 进行合并，并且创建新的状态 S4。当然，您还可以选择保留版本 S3 （“地雷”）或者版本 S2 （“建议的”）来解决冲突。当冲突解决时，被视为合并的。
对于本次讨论中的余下部分，要更好地说明可能发生的冲突，以及如何解决它们，我们将使用JUnit 实例工程。在这个工程中，我们有两个开发人员，Markus Kent 和 Bill Cassavelli，他们都进行变更。Markus 快速修改，并将他的变更交付到流上。当 Bill 在工作区中接受其变更时，他通常不得不解决冲突。图 1 显示了实例工程的布局。
图 1：实例工程
一种防止冲突的方法是避免它们。Jazz 提供了与您向相同的流交付的其他团队成员做出的变更的察觉功能。有时候您可能想要在继续修改之前接受引入的变更，而有时候您可能决定等待并在之后进行集成。这真的依赖于您正在进行的变更的范围和类型，不论您应该马上接受与否。
让我们回到实例上。Bill 在其工作区中修改了一些文件。Markus 也修改了一些文件，并且将那些变更集交付到流上了。Bill 决定他想要对SimpleTest 类进行变更。他注意到了引入箭头，如图 2 所示，意思是，他正引入影响该类的变更。
图 2：引入变更标示
要更好地了解文件发生了什么变化，他选择了该文件，并且使用环境菜单中的 Team > Show Pending Changes 命令，在 Pending Changes 视图中显示文件（参见图 3）。所有影响该文件的引入变更集都高亮地显示。他可以双击每个变更来查看变更的实际细节。Bill 可以在继续之前接受 Markus 的变更来避免冲突。
对于您的工作区中的每一个没有交付的变更来说，很有可能其他人在另一个存储库工作区或流中的相同的文件进行变更。如果在另一个流或工作区中存在该文件的分支，那么我们称之为潜在的冲突。对于您在处理的每个文件，Jazz 不会持续地追踪所有它的分支，相反它追踪您在进行的变更和您当前流目标中的变更。潜在的冲突是您的工作区和当前流目标的属性。当您变更了您当前的流目标，潜在的冲突也可能变更。
Jazz 提供关于潜在冲突的察觉功能。当刷新 Pending Changes 视图时就检测潜在的冲突，如图 4 所示。当您在 Pending Changes 视图中选择一个文件时，为了很容易地找到对相同文件进行的变更，它将高亮显示其他的文件。您可以打开比较编辑器来查看每个变更集中的变更。
另外，如图 5 所示，package explorer 在可能有潜在冲突的文件上显示了标记。直到存在实际的冲突，比较编辑器才会一起显示冲突的变更。这会让您浏览引起潜在冲突的变更，但您不需要解决。
您不能带着潜在的冲突交付。您要么从存储库工作区中去掉变更或变更集，要么如下一个部分中见到的，您可以接受或解决所生成的冲突。要去掉变更，如果没有完成（并且还没有引入到以前的冲突中）您可以从变更集中取消它，或者您可以抛弃或者悬挂整个变更集。图 6 显示了当 Bill 悬挂了与 Markus 引入的变更集有潜在冲突的变更集之后的 Pending Changes 视图。Pending Changes 视图中不再出现潜在冲突的标志。
当您将变更接受到存储库工作区中时会发生冲突。然而，潜在的冲突是当前流目标的函数，不是固定的，冲突是存储库工作区的属性，并且与之同在，直到被解决。目前有两种主要的向您的存储库工作区中增加冲突的 UI 行为：
- 接受变更
- 当从您协同操作的流中接受代码时，Pending Changes 视图中可能出现冲突。
- 当从工作项或另一个工作区的或流的历史中接受变更集之后，可能出现冲突。
- 恢复悬挂的变更也可能引入冲突。
一旦您决定接受标记出潜在冲突的变更，您的存储库工作区中就将包含必须解决的冲突。当您接受变更并且看到不可避免的潜在冲突时（也就是，您想要向流目标交付该变更），您就知道您将需要合并。在引入冲突之前，有两种处理冲突的方法，Proactive Merging（前置合并）和 Procrastination Merging（延迟合并）。这真的是工作风格的选择。
- Proactive Merging（前置合并）：用第一种方法，您希望将合并引入的变更置于您的工作之上。基本上，您希望在比较编辑器中清楚地看到其他的变更如何应用于您的工作内容中。没什么特别要做的，您只需接受引入的变更。并不是所有变更都将应用，因为它们是冲突的。您在自己的工作之上合并建议的变更以解决冲突。
- Procrastination Merging（延迟合并）：用第二种方法，您希望在别人做出的变更之上合并您的变更。基本上，您保持与流的一致，然后在上面重新应用您的变更。要这样做，您需要悬挂正在进行的变更集，接受引入的变更，然后恢复您悬挂的变更集。并不是所有变更都将应用，因为它们是冲突的。您在新的当前环境之前合并您做出的变更。此方法只能在您第一次遇到关于您的变更时使用。一旦您进行了一些合并，并且解决了冲突，那么您就不能再悬挂变更集了，因为那样会再次引入您之前解决了的冲突。相反，您会希望使用前置合并的方法。
潜在的冲突没有冲突那样紧急。决定什么时候处理潜在的冲突总是取决于您。一旦您遇到了冲突，也是由您决定什么时候以及如何解决它们。所有的冲突解决都出现在 Pending Changes 视图中。虽然未来我们将会在其他 UI 中显示冲突和潜在的冲突，但是对冲突的处理都只出现在一个视图中。
在 Jazz 中，冲突分为两类：内容（文件的内容产生分支）以及结构的。内容冲突经常出现。结构的冲突倾向于在进行重构时出现。可能出现的结构的冲突是：
- 两个人添加了相同的文件或文件夹（也称为“邪恶的双生子”冲突）
- 一个人向另一个人删除的文件夹中添加（或移动）文件或文件夹
- 一个人移动或修改另一个删除的文件或文件夹
- 两个人移动相同的文件或文件夹到不同的位置，或者将相同的文件或文件夹重命名为不同的名称。
- 一个人向另一个人已经添加了文件或文件夹的文件夹中添加同名的文件或文件夹。
有些冲突比其他冲突更容易解决。有自动可解决的冲突，对此 Jazz 能够为您合并变更。有您需要决定如何合并的实际的冲突。还有偶然的冲突。这些是由于另一个冲突而不能应用的变更。当您解决实际的冲突时，根据您决定如何解决冲突，与此同时那些偶然的冲突将自动地解决。
橘色表示潜在的冲突，红色表示冲突。每个冲突都带有工具提示，介绍该冲突，以及可能发生的可能行为。图标提示是否是结构的或是内容的冲突。浅灰色的冲突是偶然的冲突。在图 7 中，Bill 修改了 AllTests.java。Markus 也修改了相同的文件。Bill 在他的存储库工作区中接受了 Markus 的变更，而现在 AllTests.java 上有一个冲突。工具提示进一步说明了该冲突，以及如何解决它。
图 7： 工具提示说明了如何解决冲突的文件AllTests.java
那么现在您遇到一个冲突，您有什么选择吗？有许多选择！您可以取消引起冲突的变更。您可以再次浏览您的变更，以便不再出现结构的冲突。您可以合并内容。您可以将引入的文件或文件夹移动到工作区中的其他位置。您可以让其他人回复它们的变更集。您可以放弃变更集（您的或者接受的变更集）。只应用您自己的变更。只应用接受的变更。这全都依赖于冲突的类型和您想要如何解决冲突。以下实例说明了您可能遇到的最普遍的冲突类型。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780873/viewspace-582419/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14780873/viewspace-582419/
扫一扫
519
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
