UML软件工程组织

 
更多技术资源 文章，讲座 ,培训，咨询 请访问 www.uml.org.cn

 
Rational ClearCase Multisite 简介
 
作者：慧波 商 丽 史新 转自：IBM
 
本文内容包括：
CearCase Multitsite 产品的开发和实现增强了ClearCase产品的功能。使用Multisite使分布在各个国家，或者不同地点的开发者能够对同一个VOB, 或是同一个VOB里的element 进行处理。事实上，Multisit的机能就是要使每一个地点(site)都拥有一个核心VOB在本地的复本，在任何时候，不同的地点都是在自己本地的VOB复本里面进行操作。如何保证各个地点的VOB数据能够同步呢？答案是通过相互传送数据更新包来保持数据的一致性。而这种更新操作是可以被设置为自动完成，也可以使用命令手工完成。

ClearCase Multisite 产品在什么情况下适用呢？ClearCase Multisite的设计是为了协助跨地域进行相对独立却又有联系的大规模的开发测试项目。例如：一个开发的机构他的组织非常的庞大，它的中心机构设在美国总部，但是它的开发及测试小组可能遍布于全世界各地。那么在这种情况下，如果想要集中他所有的开发和测试人员在美国开发项目就是非常不客观的。这时就需要引用ClearCase Multisite这个产品来解决这个问题，也就是说，每个开发小组所在地都保留并维护着一个对处于美国总部的各个VOB的复本，各地的开发小组使用ClearCase Multisite 来进行产品的分布式开发，从而解决了开发的跨地域性问题。

不仅仅如此，Multisite 也可以引用在单一的一个地理位置，有三个基本作用，一个是可以实现独立的开发小组共同使用统一的开发数据；另一个用途是使VOB 可以在混合操作系统平台的环境中工作；还有就是对核心VOB的备份等等。举个例子，如果你想将开发工作从Unix平台转移到Windows平台时，你只需在Windows平台上建一个对Unix平台上VOB的复本，而不是试图在Windows上连接Unix平台上的VOB, 毕竟在混合系统环境中做VOB的导入导出是相当费力的。

下面，本文将从几个方面分别介绍ClearCase Multisite产品的一些概念、特性和基本的操作。

一、 VOB 和VOB 的复本 （VOB Replicas）

二、 实现独立开发的重要机制：Mastership

三、 ClearCase Multisite的两个基本操作：复制(create VOB replica)和同步(synchronize replica)

四、 UCM Deliver/Rebase 在Multisite操作中的应用实例

一 VOB 和VOB 的复本 （VOB Replicas）

VOB（Versioned Object Base）是ClearCaes中最基础的概念，也是使用频率最高的术语之一。VOB提供了对于整体的目录结构，包括文件夹，文件，和连接的永久存储。VOB中的文件，文件夹，以及连接的历史版本都存储在存储池目录的数据容器中。你可以把VOB看成是一个小型的数据库，在这个数据库中不但记录了已经被实施了版本控制的文件系统对象的所有发展过程的数据，例如版本信息，并且还记录了相关的元数据（metadata），例如：版本标签（label），超级连接（hyperlink），配置记录等。

我们了解了VOB,再来看一下VOB的复本（VOB Replicas）。为了实现ClearCase Multisite，我们需要在不同的地点进行VOB的复制。VOB的复本也像一个常规的VOB一样，用户可以在VOB复本内进行各种各样的操作，例如checkout, check in, edit, 实行软件的编译，可以创建元数据（metadata），并且可以将元数据附加到对象中（这句话可能比较难理解，举个例子：我们创建一个label, 并且把label附属到某一个元素上）。下面的图里面例举了一个Multisite的例子：欧洲的site将美国site的VOB进行了复制，复制过来的VOB replica里面的内容和原来的VOB相同，但是在usa_branch上，欧洲site只有只读的权限。

对于大多数开发用户来说，他们不必知道VOB被复制了几份，但是他们需要意识到开发是并行的。也就是说，他们在一个branch上的进行了修改，其他的地点可能在另一个branch上也进行了修改，这些修改最终是要协调合并到一起的。

二 实现独立开发的重要机制：Mastership

为什么要引进mastership的概念？由于各个地点使用自己创建的VOB replica进行独立的开发，那么就有可能出现修改上面的冲突，比如大家都需要修改某一个文件。为了避免这种冲突，ClearCase Multisite支持mastership的机制，只有具有mastership的site，才可以修改，或者执行其他操作，也就是说mastership能够实现"修改权限互斥"的机制。

基本上所有的VOB object都有自己的宿主replica（master replica），下面以Branch这个object为例进行详细说明。

先理解一下branch 类型和branch这两个概念。branch类型，其实可以简单的理解成branch的名字，branch其实是branch类型的一个实例（instance）。如果你想建立一个名为usa_branch的branch，必须要先在VOB里面建立一个名字为usa_branch的branch类型，当你拥有了这个叫做usa_branch的类型之后，才可以建立叫做usa_branch的branch实例。再形象些说，usa_branch是branch类型，acc.c@@/main/usa_branch和resource.h@@/main/usa_branch就是两个branch实例。

在VOB中定义的每一种branch类型都有自己的master replica，包括"main"这种branch的类型。我们可以通过下面的命令来看branch类型的master replica在哪个replica上。

multitool describe brtype:usa_branch@/vobs/dev
branch type " usa_branch "
created 16-Aug-00.18:12:23 by John Cole (jcole.user@goldengate)
" usa branch for work on dev project"
master replica: usa_hub@/vobs/dev
...

为什么要反复强调branch 类型的master replica的概念呢？因为在缺省的情况下，branch实例只能在那些branch类型的master replica上建立。就上面那个例子，我们看到usa_branch这个branch类型他的master replica是 usa_hub，那么usa_branch实例也只能在usa_hub这个replica中才能生成。Branch 生成好了，如何看branch实例的master replica是哪一个呢？ 命令如下

multitool describe test.txt@@/main/usa_branch
branch "test.txt@@/main/v2.0_port"
created 18-Aug-00.10:50:34 by John Cole (jcole.user@goldengate)
branch type: usa_branch
master replica: usa_hub@/vobs/dev (defaulted)
...

上面介绍了建立branch应该具有的mastership是什么（就是在具有branch类型的master replica上建立）。那么当我们生成了branch之后，对branch上面的元素（element）, 如文件，文件夹，进行checkout, checkin的动作，实施这些动作需要什么样的权限呢？那就是要对元素所在的branch有mastership。例如前面提到的text.txt的例子，

multitool describe test.txt@@/main/usa_branch
branch "test.txt@@/main/usa_branch"
created 18-Aug-00.10:50:34 by John Cole (jcole.user@goldengate)
branch type: usa_branch
master replica: usa_hub@/vobs/dev (defaulted)
...

从上面的命令结果，可以得到这样的结论：由于usa_branch的master replica是usa_hub，要想对text.txt实施reserved checkout，checkin， 只能在sua_hub这个replica上操作。

通常所提倡的Multisite的开发模式，可以用图示的例子说明：开发在两个地点进行，一个是main site，一个是USA site，在各自的开发点上，开发是在不同的branch上面进行的。Main Site是在main的branch上进行，它在main的branch上有mastership，而在usa_branch上面没有mastership，是只读的。USA site相反，它是在usa_branch上有mastership，而在main上面没有mastership。所以两个site的可以并行开发但是并不互相干扰。

前面的用了大量的篇幅描述了branch的mastership，那对于其他的VOB object，他们的mastership又是怎么样的呢？当你在本地创建了一个VOB的replica之后，这个新建的replica缺省的就成为你在这个新创建的replica中所创建的所有object的master replica。我们可以用describe命令去查看他们的master replica是什么：

比如：

查看VOB复本的master replica：

cleartool describe replica:usa_hub@/vobs/dev

查看工程（project）的master replica：

cleartool describe project:proj_site1@/vobs/dev (/vobs/dev是ucm project vob的tag)

查看流（stream）的master replica：

cleartool describe stream:tester_proj_site1@/vobs/dev

新创建的objects只能在它的master replica来控制和管理，你可以修改，删除这些object。当然你也可以将object的mastership的权限转移给其他的replica，那么接收到mastership的replica也就成为了master replica.

三ClearCase Multisite的两个基本操作：复制和同步

（一）复制 (create VOB replica)

复制VOB需要进行以下三个步骤：

1， 导出：在某一地点的主机上，输入mkreplica -export命令，这个命令的执行结果是生成一个新的VOB复本（replica）和装有VOB复制信息的包。

2， 传输：将步骤1中生成的包发送到其它的地方的主机上。

3， 导入：在另一地点的主机上接收并倒入带有VOB复制信息的包。

下面将对make replica的过程作以详细的介绍。

复制VOB之前的准备工作：

  • 确保是否已经获得了ClearCase Multiste 产品的使用许可。使用mkreplica -export命令，只有ClearCase的使用许可是不够的，还必需持有Multisite的使用许可。
  • 在进行复制前，要在原始VOB上打上基线（如果你使用的ClearCase UCM）或者加上标签（apply label）。这样在新的VOB上工作的开发人员就可以在使用新VOB之前在这些基线（baseline）或者标签（label）的基础之上创建分支（branch），然后在这些分支上开始开发工作。
  • 为原始VOB的replica 对象更改名字。即使这个VOB从来没有被复制过，这个VOB的数据库中也已经存在一个replica 对象，叫做：original。可以使用以下命令查看这个replica对象：
    > cleartool lsreplica -invob /vobs/dev 使用以下命令对original 改名：
    > multitool rename replica:original main_hub （名称改成main_hub）
  • 在对VOB进行复制之前还要确保VOB并没有被锁住。用下面这个命令来查看VOB的状态：
    > lslock vob:/vobs/dev
  • 查看VOB数据库的大小。在mkreplica 的命令里有个参数是 -workdir, 这个参数是用来指定执行这个命令时的工作目录的。所以这个指定的工作目录必须足够大，足以容纳这个VOB数据库。因此在执行mkreplica之前，得到VOB数据库的大小是非常必要的，有利于指定一个合适的工作目录。而且执行该命令的用户还必须对这个工作目录具有可写的权限。察看VOB大小的命令：
    > cleartool space /vobs/dev

导出阶段:

  • mkreplica -export 命令，例如：
    这条命令的任务有两个，一是在另一个主机上新建一个复本VOB，另一个任务是把本地VOB的信息打包。例子用到的参数 -fship是一种传输方式，在下面会提到。
    > multitool mkreplica -export -workdir /tmp/ms_wkdir -fship AIX_HOST:usa_hub@/vobs/dev
  • 备份原始的VOB。我们这里所说的备份是经过复制之后的VOB。如果你使用复制之前的VOB进行恢复，由于源VOB又被标志成了非复制的状态，所以导致Multisite的 VOB复本恢复将失败。
  • （可选项）验证与复制相关的变化。
    下面的这些命令可以帮助你检查目前你都做了哪些与复制相关的工作。mkreplica命令使得在数据库中创建了一个新的VOB复本 对象，你可以直接把VOB复本对象理解为VOB对象。它的属性可以用lsreplica命令显示：
    > multitool lsreplica -invob /vobs/dev
    For VOB replica "/vobs/dev":
    15-Aug.14:19 tester replica "main_hub"
    16-Aug.09:49 tester replica "usa_hub    "
    　

    lshistory 命令显示了与复本对象相关的所有事件。

    > cleartool lshistory replica:usa_hub@/vobs/dev
    16-Aug.09:45 tester rename replica " usa_hub" "Changed name of replica from "original" to " usa_hub"."
    15-Aug.14:19 tester make attribute "FeatureLevel" on replica usa_hub"

传输阶段：

传输过程也就是将生成的复制包传送到一个新的地点，传输的方式因为在 mkreplica -export里所使用的参数不同而不同：

  • 如果使用的是-fship参数，这个包将会立刻被传送到另一个地点的主机上。
  • 如果使用的是-ship参数，就必须运行shipping_server传送包。
  • 如果使用的是-tape 参数，那需要使用磁带或者其它介质协助传送包。

导入阶段：

  • 在准备接收的主机上，可以用lspacket这个命令来查看所有接收到的包，例如，AIX_HOST是准备接收包的主机：
    AIX_HOST> multitool lspacket
  • 执行mkreplica -import 命令
    VOB 的replica 也是有权限控制的。mkreplica -import命令执行完毕，执行这个命令的用户将会变成VOB replica 和这个VOB replica所有元素的owner。
    同样的，-workdir指定的工作目录也必须足够大，需要有至少1.6GB的可用空间。
    必须具体指明输入包的所在目录。
  • 删除replica-creation 包，replica 更新包会自动删除。

（二）手工同步 (manual synchronize replica)

导出阶段

使用syncreplica -export 命令和正确的参数生成更新包。如果你的机器处于网络环境中，可以使用-fship参数直接将更新包传输到另一台主机上。

例如：
> multitool syncreplica -export -workdir /tmp/ms_wkdir -fship aixmachine

传输阶段

如果在syncreplica -export命令中使用了-fship参数，更新包会直接被传送到另一台主机上；

如果在syncreplica -export命令中使用了-ship参数，会以两种方式调用shipping_server： shipping_server -poll and shipping_server shipping-order-pathname.

如果不是用-fship 或-ship 参数，可以使用mail或其他的传送方法来传送包。

如果使用其它传输介质进行传输，直接将包拷到主机的相应位置即可；

导入阶段

使用lspacket命令确认已经接收到更新包。

使用syncreplica -import 命令，把更新包的内容导入到VOB replica。例如：

> multitool syncreplica -import -receive

这里使用-receive 参数，意思是接收在incoming shipping目录下所有能够找到的包；

> multitool syncreplica -import c:\msite\packet

这个例子指定了一个目录作为参数，syncreplica -import 命令会从c:\msite\packet 目录下找所需要的更新包，然后把这些更新应用到vob replica上。

四UCM Deliver/Rebase 的应用实例

场景介绍：

在这个例子里面，一个大型软件公司的核心开发部门在北京，同时在上海也设立了开发部门，负责另一个模块的开发工作。现在有两台开发用的主机Site1 和 Site2 分别位于北京和上海的软件开发组。

公司的策略是使用Rational ClearCase Multisite产品来进行软件开发的版本控制。主要使用ClearCase的UCM，在Site1 上创建开发所使用的Project VOB 、 Component VOB和 Project，同时，Project的Integration View也是在Site1上生成的。Site2（上海）方面，需要创建Site1 上的Project VOB和 Componet VOB的replica，然后join Project VOB上的Project，进行软件开发。最后将dev stream上的成果deliver到Site1上的集成流上；同时也可以将Site1上集成流的更新rebase到本地的开发流上。这里，以Site1 是windows操作系统，而Site2是Unix或Linux的操作系统为例，同时介绍如何利用Multisite来实现ClearCase的interop操作（混合操作平台）。

（一）在Site1上搭建UCM 的开发环境

  • 在 Site 1 (Windows OS)上，使用图形界面来创建Project VOB和 Componet vob，Click:
    Start -> All Programs -> Rational Software -> Rational ClearCase -> Administration -> Create VOB，
    Project VOB：Win_PVOB 和 Componet VOB：Win_CVOB 创建成功。
  • 在ClearCase Project Explorer里创建Project及Join project

（二）在Site1上创建VOB replica

  • 创建VOB replica的过程需要在视图的环境里完成的，所以在执行mkreplica命令创建VOB replica之前，需要新建一个视图：myview。
  • 在myview 视图的环境下，进入到Win_PVOB的目录，将Win_PVOB的replica 名字从orginial 改成 win_pvob，用来唯一标识Win_PVOB在Site1上的 replica 名字：
    > multitool rename replica:original win _pvob。
    同样地,更改Win_CVOB的replica的名称:
    > multitool rename replica:original win _cvob.
  • 创建VOB replica：
    创建Win_PVOB在Site2的replica：
    > multitool mkreplica -export -workdir c:\temp\workdir -nc -fship <machine name2>:unix_ rpvob.
    其中, -export 表示mkreplica所执行的结果是要生成包含replica信息 的包，并按照相应的参数将这个包传输到相应的主机； -workdir 参数所指明的是一个工作路径。在mkreplica -export执行的过程中，需要一个工作路径来存放生成的临时数据， workdir参数所指明的这个目录就起到了存放临时文件的作用。所以这个目录需要足够大，能够容纳整个VOB的内容； 参数-fship表明，传入包时需要使用shipping_server，并且这个包是在生成之后立刻被传送到Site2的； <machine name2>所指的是Site2的机器名，因此在执行此命令之前，需要保证Site1可以通过访问机器名来访问到Site2； 这里的unix_rpvob 是你要在Site2上创建的Win_PVOB的replica的名字，你可以任意命名这个名字，不过还是建议您按照一定的规则来命名， 例如：名称里包含site的信息，VOB的信息，用来标识这个replica是在哪台机器上的，是属于哪个VOB的replica。
    同样的方法创建Win_CVOB在Site2的replica：
    > multitool mkreplica -export -workdir c:\temp\workdir -nc -fship <machine name2>:unix_rcvob

(三) 在site2上导入VOB replica

  • 查看在Site1上执行完mkreplica -export后传送到Site2的包。在Site2 ( Unix machine)上执行：
    >cd /usr/atria/shipping/ms_ship/incoming
    >ls
    这时，在这个目录下已经存在了两个文件，这就是从Site1上传输过来的包含有新建的replica信息的包。或者执行multitool lspacket，也可以查到所传入的信息包的位置。
  • 导入包，在Site2上导入replica。
    在Site2上创建Win_PVOB的replica VOB：
    > multitool mkreplica -nc -import -vre unix_rpvob -workdir /var/tmp/workdir -tag /var/tmp/Unix_rPVOB -vob /var/tmp/ Unix_rPVOB.vbs -npreserve <packet name>
    其中：import参数表示mkreplica命令要执行导入replica 包的操作；-workdir后面的参数表示存放临时数据的工作目录，这个目录需要具有足够的空间；-tag 参数表示在Site2上要创建新的replica VOB的tag；-vob参数表示VOB 文件的存储路径；-npreserve参数表明采用不保持和export Site一致的用户和权限创建replica VOB, <packet name>是指/usr/atria/shipping/ms_ship/incoming目录下的文件名，根据VOB名称选择不同的packet 名。
    同样地，在Site2上创建Win_CVOB的replica VOB：
    > multitool mkreplica -nc -import -vre unix_rcvob -workdir /var/tmp/workdir -tag /var/tmp/Unix_rCVOB -vob /var/tmp/Unix _rCVOB.vbs -npreserve <packet name>
    　
  • Site2上Mount已经导入的replica VOB:
    > cd /var/tmp
    > mkdir Unix_rPVOB
    > mkdir Unix_rCVOB
    > cleartool mount /var/tmp/ Unix_rPVOB
    > cleartool mount /var/tmp/ Unix_rCVOB
    　
  • 在Site2上执行一些操作：
    Join Project；在开发视图的环境下，在Unix_rCVOB根目录下里创建一个文件，将文件加入源控制；将Site2上开发流上的变化deliver到集成流上：在project explorer里，右键点击Site2的开发流，选择"deliver > to Default"。由于集成流的mastership是Site1 上的replica, 所以，此时deliver的操作只是成功的把需要deliver的要素传到Site1的replica上，如图：


    图中所示是deliver成功后的结果，并且提示您如果想完成deliver的全部操作请到site1的replica上面执行。在此之前，需要进行site1和site2的同步操作，将Site2上的变化传到Site1上。
    　

（四）同步操作：

  • 在Site2的命令行里，执行以下步骤：
    > cleartool mkview -tag non_ucm_view /var/tmp/non_ucm_view.vws
    用来创建一个普通的视图。（不是一个UCM的视图）
    > cleartool setview non_ucm_view
    > cleartool mount /var/tmp/Unix_rPVOB
    > cd /var/tmp/Unix_rPVOB (进入到PVOB的根目录)
    > multitool syncreplica -export -fship win_pvob
    这里，syncreplica 是同步命令；-export 表示同步后要输出包；-fship表 示shipping_server立刻将包输出到相应的replica；win_pvob是这个Project VOB在Site1上replica的名称。
    同样地，在non_ucm_view的环境下，
    > cd /var/tmp/Unix_rCVOB
    >multitool syncreplica -export -fship win_cvob
    　
  • 在Site1上接收同步包：
    > multitool syncreplica -import -receive
    　
  • 在Site1上完成deliver操作：
    在Project Explorer，选中Win_Pvob > project, 选择 Tools > Find Posted deliveries，在Find Posted Deliveries窗口上，选择Site2的开发流，如 图：



    选择"deliver"，完成deliver操作，是site2上开发流的变化集成到project的集成流上。



    delivery全部的操作成功完成后，会看到一个成功的提示，如图：

(五) 在Site1上，将集成流上的变化rebase到Site1的开发流

rebase Site1的集成流变化到Site1的开发流，使得Site1上也得到最新的资源。由于集成流和Site1的开发流的mastership都是Site1的replica, 所以能够在Site1上完成这个rebase操作，而无需同步到Site2上。完成rebase 需要两个步骤：

  • 在project explorer中，在集成流上新建一个baseline；从这个baseline上rebase到开发流。
  • 选中开发流，右键，选择rebase stream。到这为止，Site1和Site2上的开发流内容完全一致（私有文件除外）。下面的图示就是在site2的开发流上操作rebase from recommended baseline。

（六）将site1的集成流变化rebase 到site2的开发流

如果需要将Site1开发流上的变化同步到Site2的开发流上，例如在Site1的开发流环境中，在Win_CVOB里新建了一个文件，需要将这个文件同步到Site2的开发流上，需要经历以下步骤：

  • 首先，需要将project的集成流的mastership改成Site2的replica：
    在non_ucm_view 的环境中，进入Win_PVOB的根目录，执行chmaster命令。
    >multitool chmaster -stream unix_rpvob stream: Win_project_ Integra tion
    Mastership was changed for all objects associated with stream "Win_Proj_Integrat ion".
    You must change mastership manually for the following branch types:
    Win_Proj_Integration@\Win_CVOB
    这里，chmaster命令的意思是要更改一个object的mastership；-stream表示要更改的object是流；unix_rpvob是要改成的replica 名称；stream 后面所带的参数是流的名称，这里为project的集成流。这个命令执行完毕，会出现一个提示，提示您需要更改branch type的mastership，并且给出了需要更改的branch type的名称，在这个例子中就是Win_Proj_Integration@\Win_CVOB。需要记录下这个branch type名，在下一步中，作为参数输入。
    　
  • 同样在non_ucm_view环境，进入Win_CVOB的根目录，执行chmaster命令，更改branch type。
    > multitool chmaster unix_rcvob brtype:<pasted branch type
    这里的brtype后接的参数需要输入上一步中在提示信息里所记录的 branch type名称。
    　
  • 将更改mastership的结果同步到Site2上：
    需要在non_ucm_view环境下，首先进入到Win_PVOB根目录，执行：
    > multitool syncreplica -export -fship unix_rpvob
    进入到Win_CVOB根目录，执行：
    > multitool syncreplica -export -fship unix_rcvob
    在Site2上，导入同步信息：
    > multitool syncreplica -import -receive
    　
  • 在Site1上执行deliver:
    在上一步中已经将集成流的mastership从Site1的replica改成Site2的replica，并且将更新同步到Site2之后，在这一步中开始在Site1上执行deliver操作，如图：




    　
  • 把Site1 的deliver更新同步到Site2上，这次不需要同步Win_CVOB了，以为Win_CVOB并没有做改动，只是将Win_CVOB的前面的更改deliver到了Win_PVOB：
    在non_ucm_view的环境下，进入到Win_PVOB根目录，执行：
    > multitool syncreplica -export -fship unix_rpvob
    在Site2上接收同步包：
    > multitool syncreplica -import -receive
    　
  • deliver执行之后，只是将结果传送到了Site2的replica上，需要继续在Site2上执行Find posted deliveries操作，从而最终完成deliver操作。

  • 当更新到达Site2的集成流后，可以通过rebase将更新传到Site2的开发流中。这样Site2的开发流和Site1的开发流就完全一致了。

五 总结

本文概括了ClearCase Multisite所涉及的基本概念，包括VOB和VOB复本，Mastership，以及完成创建VOB复本和手动同步更新的步骤。最后本文通过一个场景实例详细描述了如何用Multisite来实现一个分布式开发。希望对从事相关工作的技术人员有一定的帮助。

参考资料

  • ClearCase MultiSite Administrator's Guide

 

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号