ibm jazz_Jazz源代码管理管理指南

尽管IBM®Rational®Jazz™版本控制与其他版本控制系统具有相似的名称，但确实存在细微的差异。首先，我们将探索组成Jazz源代码管理管理（SCM）的组件。其次，我们将研究如何在Jazz SCM组件之间计算和移动更改。下图显示了所有元素的概述；

图1. Jazz源代码管理管理（SCM）图

Jazz SCM的组件

Jazz SCM的组件组成与许多可用的SCM系统略有不同。在我们继续之前，重要的是要对这些组件是什么及其预期用途有共同的了解。

变更集

变更集是文件或目录变更的集合，这些变更分组在一起形成一个单元。正是这个完整的单元被提交给单个组件并与工作项相关联。更改集是在将更改从本地工作区签入到存储库工作区时创建的。

零件

这是所有变更集和基准的最终目标。使用Eclipse或Microsoft®Visual Studio时，文件和目录分别在项目或解决方案级别共享到组件中。

流

使用流来创建变更集和基准的隔离配置，用户可以通过这些配置将其变更集交付给组件。根据IBM®RationalTeam Concert™项目的流程配置，所有用户都可以创建流或受限制的子集。

使用流来创建变更集和基准的隔离配置，用户可以通过这些配置将其变更集交付给组件。根据Rational Team Concert项目的流程配置，所有用户都可以创建流或受限制的子集。

随着新变更集的交付，流配置将更新以反映其演变。通过比较流和存储库工作区配置规则之间的差异，系统可以识别用户必须接受到其存储库工作区中才能保持与流同步的更改集。

流还是快照信息的容器。

仓库工作区

存储库工作空间是Rational Team Concert服务器上的存储区域。工作空间包含一个配置，该配置由组件和基准组成，用于保存未交付的变更集和基准的存储（尚未存储在组件内），以及用于尚未升级为流的快照的存储。可以将存储库工作空间中的变更集交付给相应的组件。

本地工作区

这是用户的本地工作站上的目录，他们已在该目录中加载了存储库工作区。用户在其本地工作空间中所做的任何更改都将被标识并突出显示为可以被检入已加载的存储库工作空间中的候选对象，并在其中将它们分组在变更集中。

基准线

当存储库工作空间代表用户想要与他人共享或标记以供将来使用的文件或目录版本的配置时，则必须创建基线。这些标记以与变更集相同的方式传递到组件。基线只能应用于驻留在单个组件中的变更集。

流量目标

存储库工作空间和流都可以具有定义到另一个存储库工作空间或流的流目标关系。每个存储库工作空间或流都可以定义许多这些流目标，但是可能只有一个活动目标。它是活动流目标，允许计算传入和传出的更改。

工作原理-基本操作

如果您使用基于Web的Rational Team Concert版本，那么您可以直接通过流使用Jazz源代码管理管理（SCM）功能，这对于诸如技术作者之类的用户来说，将其资产置于配置控制之下是一种很好的方式。他们还可以为更广泛的开发团队做出贡献并与之合作。

对于需要更多配置管理功能的开发人员，他们可以使用Rational Team Concert Eclipse IDE，Microsoft Visual Studio Rational Team Concert插件或功能丰富的Jazz SCM命令行界面。本文的其余部分假定您正在使用这些接口之一。

要使用Jazz SCM，您必须做的第一件事就是创建一个不引用任何其他组件的组件。然后，用户必须根据要使用的流创建存储库工作区。最后，用户必须将存储库工作空间加载到本地工作空间（例如Eclipse工作空间）中。

设置本地工作区后，用户可以与存储库工作区共享本地工作区中的Eclipse项目或Microsoft Visual Studio解决方案。他们可以指定其资产将驻留的现有组件或新组件。在存储库工作空间中，共享资产被组织到一个新的变更集中。

在存储库工作区中，用户可以挂起，恢复（如果以前是挂起的）或通过流向组件传递变更集。每个变更集只能驻留在单个组件中。目标组件由其中的资产确定。例如，共享操作确定要与特定组件关联的顶级目录资产。

在本地工作空间中对共享Eclipse项目或MS Visual Studio解决方案所做的任何修改都被标识为可以检入存储库工作空间的项目。在签入时，这些项目被打包在一个或多个变更集中，并且必须通过流传递到组件。

图2. Jazz SCM核心操作

采用现有的Eclipse项目或Visual Studio解决方案，并将其共享给Jazz SCM以进行配置管理。

签入更改

当用户签入更改时，他们实际上是将更改从本地工作空间打包，并将其复制到存储在存储库工作空间中的更改集。

交付

交付变更集时，您将其从存储库工作区提交到组件。

促进

升级动作意味着您将快照的存储位置从其驻留位置移动到另一个存储库工作区或流。

关联

关联变更集时，可以在变更集与Rational Team Concert工作项或OSLC变更集之间创建关系。

锁

此操作将特定资产锁定在流的上下文中，从而防止其他用户修改流。启动该流的锁定操作的用户仍然可以对其进行修改。

开锁

此操作将恢复用户修改锁定资产的能力。

暂停

此操作用于存储在存储库工作空间中的变更集。修改了存储库工作空间配置，使其不包含更改集。与存储库工作空间关联的本地工作空间会立即更新，以确保不包含更改集。更改集仍存储在资源库工作区中，可以随时恢复。

恢复

此操作用于存储库工作空间中的暂挂变更集。存储库工作空间配置已更新为包括恢复的变更集。此时，本地工作空间可能必须接受更改集并与自暂停以来所做的所有更改进行合并。

运作方式–详细考试

在本节中，我们将更详细地探讨Jazz源代码管理（SCM）在新项目中的工作原理。解释了以下方面：

默认的Jazz SCM Rational Team Concert项目中提供了什么
如何将初始资产添加到Jazz SCM
如何记录组件配置以供将来参考和共享
如何在共享代码上协同工作
如何记录流配置以供将来复制
如何创建新流并在流之间进行偏离

到本节结束时，您将对在SCM控制中添加和修改资产的进度，如何唯一标记发行版以及如何进行维护而又不影响下一个发行版的工作进行了了解。

在Rational Team Concert中创建一个项目

创建新项目时，默认行为（取决于所使用的过程模板）是针对默认组件和流自动创建的。配置流，使其与使用其初始基线的默认组件关联。这是流的初始配置。

下图显示了创建项目和与流关联的用户的存储库工作区之后的组件结构。此时，没有文件或目录已提交给Jazz源代码管理。

图3.一个新的Rational Team Concert项目的Jazz SCM状态

与Jazz源代码管理共享项目工件

根据您使用的IDE，有必要创建一个项目（或解决方案）并将其与Jazz源代码控件共享。要共享，必须指定目标组件。共享后，资产被分组到一个变更集中，并存储在存储库工作区中。为了使其他Jazz源代码控制用户可以看到和使用这些资产，必须将更改集交付给共享时指定的组件。

每个变更集都有一个唯一的编号。尽管该数字在IDE客户端上不可见，但用户可以通过Jazz源代码管理命令行界面（CLI）看到。参见图4。

图4. Jazz源代码管理CLI显示更改集编号

交付变更集后，流配置将更新以反映其当前状态是开始基准加上新变更集的组合。这些动作如图5所示。

共享操作将选定的项目/解决方案打包为一个新的变更集，并将其移至指定的存储库工作区。
传递将更改集移动到共享操作时指定的组件。
注意：查看流或存储库工作空间的配置规则时，仅显示基线。

图5.与Jazz源代码管理共享项目工件

创建组件的基准

现在，您的项目已共享，所有存储库工作区都可以访问它，并且活动流目标指向交付项目所通过的流。其他流看不到该项目，因为它包含在初始基准之外的变更集中。

新流和存储库工作空间的配置由可变数量的成对组件和基线组成。通过将诸如＃1之类的特定更改集加载到存储库工作区中并进行交付，可以手动重现所需的配置，但首选方法是创建一个新组件基线，该基线封装新的更改集及其共享项目。

用户可以在存储库工作区中创建基线，但是必须将基线传递到适当的组件。图6说明了以下操作：

创建基准操作在存储库工作空间内的组件上执行。基准对象是组件配置规则的标记。创建后，存储库工作空间的配置规则将更新以反映新的基准。在此示例中，已将规则修改为引用ComponentA的BL1。基线被临时存储在存储库工作区中。
交付操作将基线移至组件，可在其他流或存储库工作空间配置规则中使用基线。在此操作期间，通过其传递的流将更新其配置规则以反映基线，在此示例中，这是ComponentA的BL1：

图6.创建组件基准

在存储库工作空间内创建了基准1（BL1），其配置规则会更新以反映新的基准。基线现在位于存储库工作空间内，等待交付给组件。交付基准后，它将移入组件，并且流配置将更新以反映新的基准。现在可以在其他流或存储库工作空间配置中引用基线。

基线具有单个组件的范围。如果需要标记跨越多个组件的配置，则需要创建快照，这将在以后介绍。

处理共享代码

交付给组件后，资产可以以受控方式演变。需要将对资产所做的更改签入到存储库工作区中。默认情况下，用户必须启动此操作，但是使用Eclipse IDE可以在保存文件时自动执行签入操作。

对共享资产所做的修改被标识为签入的候选对象。然后，在存储库工作区中创建一个新的变更集。随后的签入操作可能会将更改与该更改集相关联，或者用户可以显式请求创建新的更改集。

在存储库工作空间中具有多个变更集的情况下，用户可以选择与变更相关联的变更集，或者允许IDE客户端选择一个变更集。如果用户选择更改集，则他们必须考虑以下约束：资产被修改并添加到更改集后，对该同一资产的任何后续更改都必须修改为原始更改集。交付变更集并且不再驻留在存储库工作空间内时，将重置此约束。

变更集与Rational Team Concert记录（或外部OSLC变更请求）的关联是可选的，但强烈建议这样做，以提高可审计性。它还有助于根据通过关联的Rational Team Concert工作项或OSLC变更请求记录标识的特定变更来构建软件。可以通过Rational Team Concert流程定制功能来实施此实践。

最后一步是通过标识为活动流目标的流将更改集交付给组件。图7中说明了以下操作：

检入操作将本地工作空间中的已修改文件和目录打包，将它们移至从中加载项目的存储库工作空间，并将其放置在变更集中。存储库工作空间的配置规则会更新以反映它现在正在使用基线BL1和ComponentA的变更集＃2的组合。
（可选）：关联操作允许用户在变更集与Rational Team Concert工作项或OSLC变更请求之间创建关联。
交付操作将更改集移动到组件。在此操作期间，通过其传递的流将更新其配置规则以反映基线，在此示例中，它现在使用基线BL1和ComponentA的变更集＃2的组合。

图7.处理共享代码，交付操作

新交付的变更集位于组件内，并且位于任何现有基准之外，并通过流和存储库工作空间配置关联。随着对文件和目录进行更多更改，流配置不断发展，出于各种原因（例如保留新配置的记录，流之间共享配置以及用于初始流配置），有必要拍摄快照并存储这些配置。

多个用户及其存储库工作空间可以将同一流用于协作目的。交付的变更集突出显示到附加到流的每个存储库工作区中，作为接受到存储库工作区中的候选对象。

图8显示了接受另一个存储库工作空间交付的更改所需的以下操作序列：

在交付变更集之后，具有活动流目标（通过其交付）的流的存储库工作空间将检测到它们的配置与流不同，并将更改集标识为需要接受到存储库工作空间中。
（可选）如果存储库工作空间已加载到本地工作空间，则接受的变更集的内容会自动加载到其中。

在此示例中，接受变更集＃2导致ComponentA的存储库工作区配置规则被更新以表示BL1加变更集＃2。此更改集的内容，文件HelloWorld.h，将自动加载到本地工作空间中。请注意，当您查看流或存储库工作空间的配置规则时，仅显示基线。

图8.处理共享代码，接受操作

创建和存储快照

图9描述了我们一直关注的共享资产的开发进度。第二个组件已创建，一些新资产已共享给它。流和存储库工作空间配置已更新，以反映以下情况：

组件A被作为基线BL1加上变更集＃2。
组件B被拾取为基线BL0.1

图9.创建快照-配置之前

工作流小组认为其配置代表其第一个发行版，并希望对其进行记录，以供审核和娱乐之用。为了实现此目标，必须创建一个新的快照。

您可以在存储库工作区配置上或直接在流上创建快照。我们将看看这两种变化会发生什么。每个都有相同的最终结果。

请注意，定义流的唯一目的是作为快照的存储容器是一种可行的策略。例如，考虑一个发布流，所有与发布有关的快照都将升级到该发布流中。除了出于诸如重建发行版（从快照配置创建存储库工作空间）之类的目的来定位快照或出于诸如维护工作之类的目的而创建流之外，永远不会主动使用该流。

在存储库工作区中创建快照

在图10中，我们说明了在存储库工作区中创建快照时发生的以下操作：

图10.在存储库工作区中创建和存储快照

请求在存储库工作空间内创建快照。可以进行两项活动：可能创建新的基准和快照。
1. 对于包括基线和变更集的每个配置规则，都会创建一个新的基线并将其放置在存储库工作空间中，以交付给适当的组件。存储库工作空间的配置规则会更改，以反映所有新创建的基准。在此示例中，ComponentA现在反映了基准Release_1.0，它也是新请求的快照的名称。
2. 将创建一个新的快照并将其存储在存储库工作空间中。快照包含存储库工作空间配置规则的副本。这允许快照用于重新创建此配置或代表新流的起始配置。
新创建的基准必须交付给组件。在此示例中，基线Release_1.0被交付给ComponentA。
（可选）由于快照是记录跨多个组件的配置的机制，因此快照非常重要，必须将快照放置在易于定位的区域。出于这个原因，将快照保存在存储库工作空间中可能不是一个好的长期安排。升级操作允许将快照从存储库工作空间重新定位到流。在此示例中，快照Release_1.0从存储库工作空间提升为流。

直接在流上创建快照

除了在存储库工作区中创建快照外，还可以直接在流中创建一个快照，如下图所示：

图11.直接在流上创建和存储快照

发出了创建快照以在流上发生的请求。结果发生了两个自动操作：创建任何所需的基准，以及创建快照。
1. 对于包括基准和变更集的每个配置规则，都会创建一个新基准并将其直接放置在适当的组件内。流的配置规则会更改，以反映所有新创建的基准。在此示例中，ComponentA现在反映了基准Release_1.0，它也是新请求的快照的名称。
2. 将创建一个新快照并将其存储在流中。快照包含存储库工作空间配置规则的副本。这允许快照用于重新创建此配置或代表新流的起始配置。
（可选）：如果创建了新的基准，那么流配置规则中的更改将导致所有具有活动流目标的存储库工作区都指向该流，以将新的基准标识为它们应该接受的东西，以与流保持同步。

流偏离并改变流之间的流量

继续我们的示例，开发团队刚刚发布了他们的第一个版本，并将其配置记录在快照“ Release_1.0”中。他们决定继续使用现有的数据流进行下一版本的工作，需要新的数据流来隔离当前版本的所有维护工作。

通过使用快照Release_1.0，将创建一个名为MaintStream的新流，其初始配置规则与快照中定义的规则相同。现在，可以在基于此流并将新流作为其活动流目标的存储库工作空间内执行与维护1.0版相关的任何活动。

有时，必须与正在进行的开发活动共享通过维护活动进行的基本错误修复。为了协调这些活动，请考虑将某人命名为“集成商”。确保此资源了解代码库，因此能够执行有根据的合并（如有必要）。执行此方案的过程包括三个不同的步骤。

第一步：创建一个存储库工作区，用于控制代码的流和集成

在图12中，概述了创建集成存储库工作区的三个步骤。

创建一个具有活动流目标和流DevStream的新存储库工作空间。
加载存储库工作空间（最好加载到干净的本地工作空间中）。
通过接受任何未完成的更改，确保存储库工作空间反映流DevStream的当前最新配置。

图12.新的存储库工作空间的配置

第二步：从MaintStream获得必要的更改，并将其与最新的DevStream代码集成

在图13中，我们显示了将MaintStream的更改吸收到集成存储库工作空间中必须发生的五个动作：

从存储库工作区中创建一个新的流目标，以流MaintStream，从中获取错误修复程序。
使这个新的流量目标成为活动的流量目标。
存储库工作区将标识流MaintStream内存在但存储库工作区中不存在的所有错误修复，这也是流DevStream配置中未包括的更改。
接受所有将集成到DevStream流中的错误修复程序，以解决所有变更集依赖性。
确保可以成功构建存储库工作空间内容，并且所产生的软件通过所有必要的测试。

图13.从包含所需更改的流中接受更改

第三步：将集成更改交付给DevStream

最后要采取的步骤将现在驻留在集成库工作空间中的更改传递到DevStream中，这些步骤如图14所示。

从存储库工作空间中重新激活流目标以流DevStream。
现在，存储库工作区将标识出存储库工作区中存在但不属于开发流的传出更改。
将所有更改传递到流DevStream。

图14.提供集成的更改

翻译自: https://www.ibm.com/developerworks/rational/library/jazz-source-control-management/index.html