ClearCase培训文档

ClearCase的使用方法

这是本人在查看ClearCase使用帮助，根据自己的理解，整理，翻译出来的部分

ClearCase帮助。主要内容是一些基础的与ClearCase相关的概念，对理解ClearCase

的工作方式有一定的作用。希望这篇文档对大家有所帮助，随手翻译的文档可能存

在不少错误之处，还请大家多多指教。

ClearCase的基本概念

一、一、VOB(Versioned Object Base)：是文件，文件夹和元数据（ClearCase控制下的文件

和文件夹叫做元素(Element)，每个元素Check In形成的修改叫做一个版本(Version)）的永久存储仓库。以下是关VOB的基本概念：

1．1．一般来说一个VOB中包含了每个元素的所有版本(Version)以及诸如用来描述每个版本的标签和CheckOut注释等元数据

2．2．对一个既定的项目，依赖于管理员对项目数据的安排，可能需要访问位于不同VOB中的元素。

二、二、View：一个View为项目中所有文件的某一个版本提供一个目录树。在View中你

可以修改源文件，将他们编译成模块进行测试，将他们插入到文档中等活动。

三、三、流(Stream)：流是一个具有长生命周期的ClearCase对象。它是单个UCM项目的成

员，还是生成和记录配置的一种机制。一个流标识了当前你可以查看，修改和编译的一系列版本。

UCM使用基线(Baseline)和活动(Activities)来描述一个流的配置。当你创建一个流时，它的初始配置和基线一样（它包括某个组件的所有元素的单个版本）。当你修改流的配置时，你将这些修改指定为一个或多个活动。因此一个流就是一个给定的基线加上一个或多个活动。

以下活动将改变一个流的配置：

1. 1.从相关联的View中CheckIn版本。（一个流可以和多个View相关联）

2. 2.基线更新(Rebase)，用更近的基线取代流配置中的基线。

3. 3.交付(Deliver)，通过向整合流(Integration Stream)中添加在此之前只有正在

开发队伍可以进行的活动改变综合流。

一个项目包含以下两种流：

1. 1.开发流(Development Stream);

2. 2.整合流(Integration Stream);

开发流：

一般来说每个项目中包含多个开发流（每个项目中的开发人员一个），它们都从同一个基线开始，而当开发人员添加活动时相互之间没有关联。

整合流：

每个项目都有一个单一的整合流来从开发队伍中成员的开发流中收集他们的提交(Deliver)。为了方便提及过程，每个开发队伍中的成员都关联一个独立的整合View

到项目的整合流。通过该整合View，开发人员可以查看基线和所有提交活动。

四、四、项目(Project)：一般意义上项目指一群人为一个开发成果而工作，但在ClearCase

中项目则是指一个说明了某一个重要开发成果中使用的一系列的开发策略(Development Policy)和一系列配置的对象。你可以为你开发的每一个产品建一个项目，也可以为多个产品建一个项目，还可以为产品中的某个功能的实现建一个项目，甚至可以为你的某个产品的一个发行版本(Release)建一个项目。

一个项目的策略决定了开发人员如何访问，修改一系列的源文件和文件夹（以上叫做组件(Component)）。为了记录和配置依赖于组件的开发成果，项目使用了以下的ClearCase对象：

1．1．基线(Baseline)；

2．2．一个整合流(Integration Stream)；

3．3．开发流(Development Stream)；

4．4．活动(Activity)；

因为ClearCase支持平行开发，不同的项目可以相同的源文件的不同版本同步工作。

ClearCase将项目储存在叫做PVOB(Project Versioned Object Base)的数据仓库中。

五、五、基线(Baseline)：在UCM模型中，当一个ClearCase对象典型地代表一个或多个组

件地稳定地源配置时，项目经理就生成基线。基线标识了一个组件或多个组件中所

有元素(Element)的某一个版本和这些元素的活动。简单的说，基线就是组件的一个版本。

你可以从基线生成开发流或者为一个已有的开发流基线更新(Rebase)。

完善的基线(Recommended Baseline):

一般来说基线会在测试和修改Bug之间不停的循环直至在稳定性上达到一个比较令人满意的程度。当一个基线达到这种程度，项目经理就指定该基线为完善的基线。

六、六、合并(Merge)：合并是指将两个或两个以上的版本联合成一个版本，ClearCase的合

并算法和下列版本相关：

1．1．合并文件：一个开发流中的版本和一个整合流中的版本；

2．2．基本合并文件：原版本的最常用的父亲版本；

3．3．目标版本：合并的输出，在提交操作中成为整合流中的一个新的版本，而在基线更新操作中将成为开发流中的新版本。

七、七、提交(Deliver)：一个允许开发人员通过将他们的开发流中的工作成果合并(Merge)

到项目的整合流中来和开发队伍中的其它成员共享他的工作成果。假如需要的话提交需要用合并管理器(Merge Manager)来合并不同的版本。

ClearCase的提交操作使得在开发流中做的工作能在整合流中得到。工作是通过活动的形式来提交的，整合流中已有的版本和提交的版本之间的差别通过合并管理器(Merge Manager)解决。和活动相关的版本在提交之前必须CheckIn。还要注意只有活动在上一次从该开发流中提交之后有改动之后的“提交”才能认为是真正的提交。

一个提交过程可以由以下几个阶段构成;

1. 1.预览，列出流中有没有完成提交工作的活动；

2. 2.开始提交，本阶段确定需要提交的活动，检查他们是否在上一次提交之后被

修改过，要提交的版本是否已经被CheckIn到开发流中。

3. 3.合并差别，本阶段比较被提交的版本和整合流中相对应的版本，如果需要的

话激活合并管理器进行合并。

4. 4.结束合并，本阶段校验合并，CheckIn整合流中的变化，进行其它一些管理工

作。

八、八、基线更新(Rebase)：ClearCase中通过基线更新使得开发人员能用整合过的，测试过

的，经过不同方面使用验收的工作成果来更新他们的开发范围内的工作成果从。这些新的工作成果被成为基线。由项目经理来将活动提交进基线。

UCM概念

一、什么是UCM

UCM(Unified Change Management)是Rational公司在软件系统开发中从需求到发行过程中对更改的管理方法。UCM横跨整个软件开发的生命周期，定义了对需求，设计模型，文档，组件，测试用例，和源码的更改的管理。

UCM奇特的地方在于它连接了用来追踪和计划体现在工件(Artifact)的变化中的Rational项目进度的活动(Activity)。

UCM主要关注以下两个概念：

1. 1.活动是你想要完成的工作。活动可能产生于某个会议的一个文件，一个进入

缺陷(Defect)库中的缺陷(Defect)，或者是客户新增加的功能。事实上，整个开发过

程就是一个活动。

2. 2.工件是一个你想进行版本控制的物体，通常是一个文件。更具体的说，工件

可以是需求，测试，可视化的模型，源码，项目计划等等。

配置管理（Configuration Management，简称CM）在UCM中是基于活动的，它允许将测试过的产品晋升基线。

基线是在某个时间点上的一个逻辑组的项目文件。它允许开发团队在诸如发布和开发的跌代过程等关键的里程碑上把握软件进度。

组件管理(Component Management)在UCM是一种将一系列的文件版本作为一个命名的实体以产生和操作一致性的更改的方法。

UCM功能强大的地方在于它连接了用来追踪和计划体现在工件(Artifact)的变化中的Rational项目进度的活动(Activity)。UCM由以下过程和工具支持：

1. 1.Rational Unified Process 中的更改管理流程描述的使用UCM的过程；

2. 2.Rational ClearQuest管理项目的活动：任务，缺陷(Defect)，请求和功能的增加，

并提供了用以跟踪项目进度的报表和报告生成工具。

3. 3.Rational ClearCase 管理所有软件项目产生的工件。

二、UCM工作流的基本概况：

无论项目经理还是开发人员，对一个软件开发项目需要什么都有一个非常良好的理解。融合这种理解并体现了业界最好的实践经验，UCM支持了跌代的软件开发过程。开发队伍的所有成员都在一个UCM项目(Project)中工作。在UCM中项目(Project)是包含有诸如产品版本等用来管理开发成果的配置信息的对象。

一个项目包含一个共享的工作区和数个人工作区（或者叫流），个人工作区允许开发人员独立地通过活动的形式工作。而项目经理的责任就是维护共享的程序开发区。

UCM工作流：

UCM的项目经理和开发人员的工作流如下图所示。图中小标签所代表的活动由小标签上的数字所表示的工作流摘要说明：

UCM工作流摘要：

1. 1.项目经理设计出项目的范围和项目的策略；

2. 2.项目经理创建项目，设置项目的共享工作区（整合流），并为一个或多个组件

(Component)确定初始的基线。组件(Component)是在一起开发，整合，发行的一组

相关联的文件和文件夹。基线则是组件的一个版本。

3. 3.开发人员通过创建他们自己的工作区（开发流），并将项目的基线的内容导入

到该工作区来加入到该项目中。

4. 4.开发人员创建一个活动，并在活动工作一段时间。活动记录了开发人员为了

完成诸如修改一个Bug等开发任务而修改或生成的一系列文件。这些和活动相关

联的文件叫做更改(Change Set)；

5. 5.当开发人员在他们自己的私人工作区里完成活动，对他们工作成果的编译和

测试之后，他们可以通过将该活动提交到共享工作区中来和整个开发组的其它成员

共享他的新的工作成果。

6. 6.项目经理周期性地在共享工作区中通过合并已经提交的活动来生成新的基

线。

7.7.开发人员用新的基线中的新的版本的更新私人工作区。

8.8.当基线的稳定性和质量得到改善之后，项目经理周期性地调整基线的提升级

别为诸如BUILD和TESTED之类能提箱相应的项目里程碑的字眼。

开发人员在为活动工作，提交已经完成的活动，用新的基线更新自己的私人工作区中循环。而项目经理则在不停地做创建新的基线和基线升级中循环。这两个循环会持续到项目完成。

三、UCM项目中的数据流：

1. 1.项目中用于标识和隔离不同开发人员的工作的活动(Activity)从多个开发流中

迁移到标识一系列在整个项目中用于构造系统和测试用的共享版本的整合流(Integrator Stream)中。

2. 2.项目经理将已经提交到整合流中的活动收集到基线中。他们把稳定的，包含

有重大意义的改变的基线为推荐(Recommend)的基线.

3. 3.开发人员对他们的开发工作区进行基线更新以查看推荐(Recommended)的基

线所标识的工作成果。在基线更新之后，在开发工作区中有所更新的基线的版本加上还没有提交的活动的版本。

ClearCase的访问控制机制

本章节将介绍ClearCase是如何控制对它所保存的数据的访问的。

一、ClearCase访问控制的基础

ClearCase所实现的访问控制机制决定了哪些用户可以在ClearCase的中创建，读取，书写，运行，和删除数据。访问控制机制由用户之间的交互情况，用户所属的组，ClearCase 中的对象和基于用户利益考虑而访问ClearCase数据的用户处理或者是应用程序来决定的。

用户和组

ClearCase本身不实现自己的用户和组的账号。它依赖于操作系统，通过用户在操作系统中的登录鉴别用户，并由此得到决定用户进行ClearCase操作的权限的用户身份和组成员的资格。UNIX和NT中都提供了能胜任诸如ClearCase这种分布式程序权限要求的用户名和组名的网际数据库。在UNIX中，该数据库是网络信息系统（NFS，Network Information System）。在NT中该数据库则是NT域服务器系统的一部分。

在以上两个操作系统中，用户登录系统都必须要有自己的用户名，在ClearCase就把该用户名作为用户身份或叫做用户ID。一个用户ID可以是一个或多个组的成员，在这些组中有一个组叫做用户的主要组（Primary Group）区别与其它所有组。在UNIX中用户的主要组在NIS的PASSWD数据库中用户的一个数据项。在Windows NT中，当创建域用户的账号时就被赋值。ClearCase同时根据用户ID和用户的主要组来决定用户对ClearCase的对象的权限。

设置主要组（仅在Windows系统上需要进行）

因为Windows NT的一个Bug：用户通过域账号登录域之后就不能更改由Windows NT 域账号管理器所指定的该账号的主要组。这就需要为VOB的访问设置可靠的，正确的主要组。

为了绕过这个Bug，我们要求将环境变量CLEARCASE_PRIMARY_GROUP设置为正确的主要组。出于使用ClearCase的目的，通过设置CLEARCASE_PRIMARY_GROUP环境变量可以不通过域用户管理器（在Windows NT上）或者计算机MMC控制台中的活动目录用户就可以管理主要组。对CLEARCASE_PRIMARY_GROUP环境变量的赋值除了在VOB 的访问中之外并不会引起任何的安全或访问控制上的变化。没有正确设置主要组的用户在创建元素或以其它形式访问VOB时会有问题。

CLEARCASE_PRIMARY_GROUP环境变量的指（后面例子中的组名）必须是符合下列所有要求的存在的域的组：

·该组必须该用户；

·该组必须在组列表中有显示；

·它和该用户在UNIX中的主要组组名相同；

Windows NT上设置环境变量的步骤：

1．1．按下开始>设置>控制面板；

2．2．运行系统程序，并选择环境变量Tab页；

3．3．选择用户变量列表中的一项；

4．4．在变量框中输入CLEARCASE_PRIMARY_GROUP；

5．5．在值编辑框中输入组名；

6．6．按下设置按钮，然后选择OK按钮退出，在下一次登录之后，更改才会生效；Windows 2000上设置环境变量的步骤：

1. 1.按下开始>设置>控制面板；

2. 2.运行系统程序，并选择高级Tab页；

3. 3.在高级Tab页中，按下环境变量按钮；

7．7．在变量名称框中输入CLEARCASE_PRIMARY_GROUP；

8．8．在变量值编辑框中输入组名；

在Windows95和Windows98的计算机上必须通过修改AUTOEXEC.BAT文件来设置CLEARCASE_PRIMARY_GROUP环境变量的值。

有特权的用户和组

有些用户和组在ClearCase的访问控制中有着特殊的重要作用。比如，每个ClearCase 对象都有其自己的所有者，一般是该对象的创建者，他就有对该对象的特殊的访问权限。加入该对象是个容器对象，比如包含有元素的VOB对象，或者是有拥有私有文件的View对象，则容器对象的所有权将部分地决定谁有访问改容器对象所中的对象。

ClearCase中还有一个广泛的概念：特权用户，在本书中它是指被赋予进行某些关键操作的用户ID。

·在UNIX中，特权用户是指根用户（root user）;

·在Windows NT主机中，特权用户是组名为ClearCase组的组员。关于ClearCase组的信息详情可以参见配置ClearCase域用户。

无论是在UNIX还是在Windows NT上，特权用户都有权修改VOB和VOB中的对象。

用户处理

用户处理是指用户用以访问ClearCase数据而运行的应用程序。该应用程序可以是ClearCase的GUI，象Cleartool之类的命令行程序，或者是诸如访问动态View（Dynamic View）中ClearCase数据的文本编辑器之类的非ClearCase程序。当一个用户想读取或者更改ClearCase数据，则为此将进行一个相应的读取或者更改的处理。

每个处理都有以下属性，这些对访问控制是非常重要的：

·用户，启动处理的用户；

·主要组，启动处理的用户的主要组；

·追加的组列表，启动处理的用户所属的其它的组；

在本章节中，将处理的主要组和其它的组统称为处理的组。

ClearCase对象

以下ClearCase对象进行访问控制：

·VOB；

·元素（Element）和版本（Version）；

·类型和类型的实例，如：标签，分支，和属性；

·统一变更管理（UCM）的对象，如：项目，文件夹，活动和流；

·VOB存储区；

·View；

·在动态View中，View私有的文件，Views私有的文件夹，以及由这些对象生成的对象；

注意：ClearCase Scheduler自己维持访问控制机制。

所有上述的对象下列属性中的一个或多个，这些属性和访问控制相关：

·拥有者，拥有者是个用户。最初的拥有者是进行创建对象处理的用户ID。对于某些对象，最初的拥有者可以被更改；

·组。最初的组是创建该对象的处理的主要组。对于某些对象，最初的组可以更改；

·保护模式。有些对象可以拥有保护模式。保护模式分为以下几种：

·对象的拥有者的保护模式；

·对象的组的保护模式；

·其它的保护模式；

对ClearCase数据的访问

某个处理是否有权限访问一个ClearCase对象是由下列事情决定的：

·处理的用户和组；

·对象的用户和组；

·对象的保护模式，假如有的话；

当处理寻求访问一个受保护的对象时，将使用下列算法判断是否批准该访问。

1. 1.处理是否有该对象的拥有者的用户ID？

·是的：根据对象的拥有者的保护模式批准或者拒绝访问；

·否：到步骤2；

2. 2.处理是否有该对象组的组ID？

·是的：根据对象的组的保护模式批准或者拒绝访问

·否：到步骤3；

3. 3.对根据对象的其它的保护模式批准或者拒绝访问。

假如一个对象没有保护模式，则ClearCase根据对象的类别使用不同的规则来决定是否批准访问。具体可以参见后面的VOB和VOB对象的访问控制机制和View对象的访问控制机制。

有时候ClearCase只有在处理有权访问包含处理访问的对象的一个或多个容器对象时才批准该处理的访问。比如说，加入用户请求用文本编辑器在动态View中创建View的私有文件时，文本编辑器必须在想要建文件的文件夹和View本身上有写的权限。

二、二、VOB和VOB对象的访问控制

VOB是ClearCase数据的主要存储仓库。VOB本身和VOB中的对象都参与访问控制。这些对象有以下几种：

·元素和版本；

·类型和类型的实例，如标签，分支和属性；

·统一变更管理（UCM）的对象，如：对象，文件夹，活动和流；

·VOB的存储区域；

VOB的访问控制

下列VOB的属性和访问控制相关：

·拥有者。初始的拥有者是创建VOB的处理的拥有者。

·组。初始的拥有者是创建VOB的处理的主要组；

·附加组列表。初始的附加组列表在Windows VOB中是空的。而UNIX VOB的附加组列表是VOB拥有者的组列表；

VOB没有保护模式。在本章中VOB的主要组和其它组统称为VOB的组。

可以使用Cleartool Describe 命令来显示VOB的拥有者，组和附加组列表。

在VOB被创建之后，特权用户或者是VOB存储的文件夹所在主机上的本地Administrator用户（在Windows NT上）可以使用Cleartool Protectvob命令更改VOB的拥有者，组和附加组列表。

创建VOB的许可

任何用户都可以创建VOB。

删除VOB的许可

只有VOB的拥有者和特权用户才可以删除VOB。

读取VOB的许可

不可以直接读取VOB。VOB的读取操作是指对VOB中对象的读取操作。具体参见元素的访问控制和其它VOB对象的访问控制。

更改VOB的许可

不可以直接更改VOB。VOB的更改操作是指对VOB中对象的更改操作。具体参见元素的访问控制和其它VOB对象的访问控制。

运行VOB的许可

不可以直接运行VOB。VOB的运行操作是指对VOB中对象的运行操作。具体参见元素的访问控制和其它VOB对象的访问控制。

元素的访问控制

元素的以下属性和访问控制相关：

·拥有者。初始的拥有者是创建该元素的处理的用户ID；

·组。初始的组是创建该元素的处理的主要组ID。元素的组必须是它所属的VOB的组之一。

·保护模式。元素的初始的保护模式在Windows 和UNIX主机上是个不相同的：

·在UNIX主机上：假如你从一个已经存在的View私有的文件上创建元素，除非没有一类用户有写权限，否则的话该元素和该私有文件的保护模式相同；如果你用其他方法创建文件元素，该文件元素对所有类别的用户都只有读的权限；文件夹元素初始对所有类别的用户都有读，写和运行的权限。

·在Windows NT上：文件元素初始对所有类别的用户都只有读的权限；文件夹元素初始对所有类别的用户都有读，写和运行的权限。

一个元素的拥有者，组和保护模式和它所有的版本都是相同的。

你可以使用Cleartool Describe命令，或者在Windows上使用元素的属性对话框来查看元素的拥有者，组和保护模式。

元素创建以后，元素的拥有者，所属的VOB的拥有者和特权用户都可以使用Cleartool Protectvob命令更改元素的拥有者，组和保护模式。

创建元素的许可

当VOB被创建时，ClearCase会创建一个初始的元素，VOB的根文件夹。该元素是VOB 中其它元素的最高级的容器。它的初始的拥有者是VOB的拥有者，初始的组是VOB的组。只有处理的主要组是VOB的组之一时，该处理才可以创建元素。当然该处理还必须要有Check Out要创建的元素所在的文件夹的权限。详见更改元素的许可。

删除元素的许可

只有元素的拥有者，VOB的拥有者和特权用户才可以删除元素。删除元素可以使用Cleartool Rmelem 命令，是和从文件夹的某个版本中移除元素不一样。详见更改元素的许可。版本的创建者，元素的拥有者，VOB的拥有者和特权用户就可以删除该版本。

读取元素的许可

一个考虑了处理的用户和组以及和处理相关的元素的拥有者，组和保护模式的算法决定了是否准许对元素的读取。该算法参看对ClearCase的数据的访问。

更改元素的许可

处理不能直接更改元素。更改元素是通过更改元素的某一个Check Out的版本，然后Check In 新的版本来完成的。

当决定一个处理是否可以Check Out 或者Check In元素的某一个版本时并不考虑该元素的保护模式。只有以下条件中的某一个成立时处理才可以Check Out版本：·处理有元素拥有者的用户ID；

·处理的某一个组ID和元素的组相同；

·处理有VOB拥有者的用户ID；

·处理有特权用户的ID；

只有以下条件中的某一个成立时处理才可以Check In版本：

·处理有Check Out该元素的用户ID；

·处理有元素拥有者的ID；

·处理有VOB拥有者的用户ID；

·处理有特权用户的ID；

当一个文件被Check Out时，你可以通过在文件夹中创建元素或者移除元素来修改文件夹。移除元素使用Cleartool Rmname 命令，它和删除元素本身不一样，详情参见删除元素的许可。

运行元素的许可

一个考虑了处理的用户和组以及和处理相关的元素的拥有者，组和保护模式的算法决定了是否准许对元素的运行。该算法参看对ClearCase的数据的访问。

对其他VOB对象的访问控制

除了元素和版本之外，VOB还有以下对象需要进行访问控制：

·元数据类型。例如：标签类型，分之类型和属性类型；

·统一更改管理（UCM）对象，例如：项目，活动，文件夹和流；

·存储区

·派生的对象

总的来说，所有的这些对象都有两个和访问控制相关的属性：

·拥有者。初始的拥有者是创建该对象的处理的用户；

·组。初始的组是创建该对象的处理的主要组；

你可以用Cleartool Describe命令查看对象的拥有者和组。在对象被创建之后对象的拥有者，所在VOB的拥有者和特权用户可以使用Cleartool Protect 命令改变对象的拥有者和组。对象的组必须是VOB的组中的一个。

创建其它VOB对象的许可

任何用户都可以创建类型和UCM对象。但只有VOB的拥有者和特权用户可以创建存储区。

类型的实例，比如：标签，分支和属性一般来说和元素的某个版本相关联。要创建这些类型的实例，以下条件中的某一个必须成立：

·处理有元素拥有者的用户ID；

·处理的组中有于元素组相同的组ID；

·处理有VOB拥有者的用户ID；

·处理有特权用户的ID；

删除其它VOB对象的许可

对象的拥有者，对象所在的VOB的拥有者和特权用户可以删除类型，UCM对象，存储区。

诸如标签，分支和属性之类的类型一般和元素的版本相关联。一般来说加入你能创佳一个类型实例，你也可以删除该类型的实例。具体参见创建其它VOB对象的许可。此外，分支的创建者可以删除该分支。

读取其它VOB对象的许可

任何用户都可以查看类型，UCM对象或者存储区的信息。

更改其它VOB对象的许可

任何对象都可以更改UCM对象。对象的拥有者，VOB的拥有者和特权用户可以更改类型和存储区。

锁定VOB对象

ClearCase许可配置被用作为一种长期的访问控制机制。ClearCase还通过在对单个的VOB对象加锁提供一种短暂的访问控制。在最低层，你可以对单个元素，甚至元素的某个分支加锁。在最高层次上，你可以给整个VOB加锁以防止任何对VOB的修改。

在对象被加锁之后，任何用户包括特权用户和加锁的用户都无法修改该对象（但特权用户和加锁的用户可以去锁）。Lock命令可以指定可以绕过加锁对对象进行修改的用户。

锁定类型对象

可以通过锁定类型对象，防止对这些类型对象的实例的修改。例如：

·你可以将Main分支对除了一个小组的用户之外的所有用户加锁。这个小组可以对所有元素的Main分支进行整合或者和发行相关的清理工作。其它用户可以继续工作，但这可以在其它分支上进行，而不是在Main分支上。

锁定一个标签类型，防止任何用户创建和删除该标签。对某个发行版本的所有元素生成标签，然后锁定该标签，这样下次重新生成该发行版本就非常容易了。

三、三、View和View对象的访问控制

View是作为用户访问ClearCase元素和版本的媒介。和VOB以及VOB中的对象一样，View也参与了访问控制机制。为了对VOB和View数据的访问进行控制，在动态View中元素和版本的许可和View及View私有的文件或文件夹的许可必须相互作用，互相配合使用。

例如，你需要Check Out元素的某一个版本才能修改该元素。要修改的元素必须能获得Check Out的许可。在动态View中，Check Out一个版本就会生成一个View私有的文件。这时候必需要同时有在View和要创建文件的文件夹中创建文件的许可。在此容器文件夹既可以是一个元素的版本也可以是一个View私有的文件夹。

一般来说，要访问动态View中的ClearCase数据，处理必须通过下列测试：

·处理必须能访问View；

·处理必须能访问包含数据的文件夹；

·处理必须能访问该元素；

在一个快照View（Snapshot View）中，快照View的文件树的文件系统本身的许可决定了对快照View中包含有元素版本拷贝的文件和文件夹的访问。

创建，删除，更改快照View中的元素需要处理有对该元素的恰当的许可。

对动态View的访问控制

动态View的以下属性和访问控制密切相关：

·拥有者。初始的拥有者是创建View的处理的用户。

·组。初始的组是创建View的处理的主要组。

·保护模式。初始的保护模式在UNIX和Windows NT上各不相同：

·在Windows NT：View初始时对拥有者和组有读取，修改，运行许可，对其它用

户有读取和运行许可。可以通过View的属性对话框来查看View的拥有者，组和

保护模式。在View创建之后就不可以修改它的拥有者和组。可以使用Chview命

令改变View的保护模式为读写或者只读。

·在UNIX上：初始的保护模式决定于创建View的用户的Umask。Umask是UNIX

中指定没有的许可的机制。当用户创建View时，ClearCase给这个View对任何用

户都有读取，修改和运行的许可，然后去除用户指定的Umask中的许可。例如当

用户的Umask为002时，ClearCase去除了其它用户的修改许可。

创建View的许可

任何用户都可以创建View。

删除View的许可

只有View的拥有者和特权用户才能删除View。

读取View的许可

处理只有同时拥有动态View和要读取的文件或文件夹的读取许可才能读取文件或文件夹。读取某个文件或文件夹元素的版本时，处理还得有该元素的读取许可。

具体详见读取元素的许可。读取View私有的文件或文件夹时，处理还得有该文件

或文件夹的读取许可。具体详见V读取View私有文件的许可。

ClearCase使用了一个考虑处理的用户和组以及View的拥有者，组和保护模式

的算法来决定是否批准读取该View的许可。详见对ClearCase数据的访问。

修改View的许可

处理必须要有修改View的许可才能对View本身进行例如设置View的配置之类的

修改。

要在文件夹中创建文件或文件夹，处理必须同时拥有在动态View和容器文件夹中

修改的许可。如果容器文件是一个元素的版本，那么该处理还得有该元素的修改许

可。详见修改元素的许可。如果容器文件夹是一个View私有的文件夹，该处理还

必须有对该View私有文件夹修该的许可。详见修改View私有文件夹的许可。

C learCase使用了一个考虑处理的用户和组以及View的拥有者，组和保护模式的算

法来决定是否批准读修改View的许可。详见对ClearCase数据的访问。

运行View的许可

运行View的许可

处理必须要同时拥有动态View和View中要运行的文件或文件夹的运行许可才能

运行文件或文件夹。为了运行文件或文件夹元素的版本，处理还得有运行该元素的

许可。详见运行元素的许可。为了运行View私有的文件或文件夹，处理还得有该

View私有的文件或文件夹的许可。详见运行View私有文件的许可。

View私有文件的访问控制

本章节讨论动态View中的私有文件的访问控制机制。在快照View中，快照View

文件树中的文件和文件夹上文件系统本身的许可决定了最这些文件和文件夹的访

问。

V iew私有的文件和文件夹的以下属性和访问控制密切相关：

·拥有者。初始的拥有者是创建文件或文件夹的处理的用户。

·组。初始的组是创建文件或文件夹的处理的主要组。

·保护模式。初始的View私有的文件和文件夹的保护模式有两种，一种实在Unix

主机上，另一种在Windows NT主机上。

·在UNIX上：初始的保护模式决定于创建文件或文件夹的用户的Umask。

Umask是UNIX中指定没有的许可的机制。当用户创建文件或文件夹时，

ClearCase给这个文件或文件夹对任何用户都有读取，修改和运行的许可，

然后去除用户指定的Umask中的许可。例如当用户的Umask为002时，

ClearCase去除了其它用户的修改许可。

·在Windows NT主机上：View私有的文件或文件夹初始时对所有的用

户都有读取，修改和运行的许可。

可以使用Cleartool Describe命令查看View私有的文件或文件夹的拥有者，组和保护模式。ClearCase>Properties Of File和ClearCase>Properties Of Directory对话框可以显示文件和文件夹的拥有者和组。以上两个对话框中的Read-Only复选框决定所有用户是否有写的许可。

创建View私有文件的许可

处理必须同时拥有View和View中容器文件夹的修改许可才能在该容器文件中创建文件或文件夹。关于View的许可，详见修改View的许可。

如果容器文件夹是元素的一个版本，处理还必须有修改该元素的许可。详见修改元素的许可。如果容器文件夹是一个View私有的文件夹，处理还得有修改该View私有的文件夹的许可。详见修改View私有文件的许可。

删除View私有文件的许可

处理必须同时有View和View中容器文件夹的修改许可才能删除容器文件夹中的文件或者文件夹。关于View的许可详见修改View的许可。

如果容器文件夹是元素的一个版本，处理还必须有修改该元素的许可。详见修改元素的

许可。如果容器文件夹是一个View私有的文件夹，处理还得有修改该View私有的文件夹的许可。详见修改View私有文件的许可。

读取View私有文件的许可

处理必须同时拥有读取View和View私有的文件或文件夹的许可才能读取该View私有的文件或文件夹。关于View的许可，详见读取View的许可。

ClearCase使用了一个考虑处理的用户和组以及View私有文件或文件夹的拥有者，组和保护模式的算法来决定是否批准读取该View私有文件或文件夹的许可。详见对ClearCase 数据的访问。

修改View私有文件的许可

处理必须同时拥有修改View和View私有的文件或文件夹的许可才能修改该View私有的文件或文件夹。关于View的许可，详见读取View的许可。

ClearCase使用了一个考虑处理的用户和组以及View私有文件或文件夹的拥有者，组和保护模式的算法来决定是否批准修改该View私有文件或文件夹的许可。详见对ClearCase 数据的访问。

运行View私有文件的许可

处理必须同时拥有运行View和View私有的文件或文件夹的许可才能运行该View私有的文件或文件夹。关于View的许可，详见读取View的许可。

ClearCase使用了一个考虑处理的用户和组以及View私有文件或文件夹的拥有者，组和保护模式的算法来决定是否批准运行该View私有文件或文件夹的许可。详见对ClearCase 数据的访问。

对派生对象的访问控制

派生对象（DO，Derived Object）是指在动态View中使用Clearmake或在Clearaudit任务中产生的文件。以上命令在快照View中不产生派生对象。

派生对象首先应该和View私有文件一样，要有和创建View私有文件一样的许可才能创建DO。DO有自己的拥有者，组和保护模式，这些属性的初始的值的初始值的决定方法和View私有文件的一样。具体详见View私有文件的访问控制。

一个可以被共享的派生对象是指其它动态View可以通过Winking In使用的DO。共享的派生对象第一次被Wink的时候，它会被从所创建的View中提升出来成为该View的容器VOB的一个对象。该VOB对象就是共享的DO。

一个被共享的DO有其的拥有者，组和保护模式。初始的拥有者和组是共享的DO在提升到VOB中是的拥有者和组。共享DO的组必须是DO被提升到的VOB的组之一。

共享DO的拥有者，VOB的拥有者和特权用户可以使用Cleartool Protect来更改该DO 的拥有者，组和保护摸式。

Wink in共享DO到某个动态View中的处理必须要有对该DO的读取许可。ClearCase 使用了一个考虑处理的用户和组以及View私有文件或文件夹的拥有者，组和保护模式的算法来决定是否批准读取该View私有文件或文件夹的许可。详见对ClearCase数据的访问。

一个被Wink In的DO在Wink In该DO的动态View中象是一个修改时作拷贝的View 私有文件。如果你对View中Wink In的DO做如更改DO权限或更改DO本身。ClearCase 会将该DO转化为View私有的拷贝。

四、ClearCase和文件系统本身的许可

ClearCase在VOB和View的主机的文件系统中的特殊文件数中保存VOB和View的数据。这些特殊的文件树是View存储文件夹和VOB存储路径。ClearCase在创建VOB时创建VOB文件路径，创建View时创建View存储文件路径。

ClearCase管理所有对VOB和View存储文件路径的访问；用户不会直接读取和更改这

些文件夹。VOB和View的存储文件路径有文件系统本身的许可，只是由ClearCase来创建并维持这些许可。虽然是由ClearCase来管理这些文件夹的访问控制，但你还必须本章缩讲述的ClearCase访问控制机制。

注意：不要更改View或VOB存储文件路径中的文件或文件夹的文件系统本身的许可。

快照View文件夹是一个包含不受ClearCase控制的ClearCase版本和文件系统对象拷贝的文件系统本身的文件树。快照的拥有者就可以改变View中文件的文件系统本身的许可。例如View的拥有者添加或删除快照View中不受ClearCase控制的文件夹中的文件的组的修改许可。

和动态View一样，快照View也有存储文件夹，它可以在View文件中也可以不在View 文件夹中。ClearCase如同对动态View一样为快照View创建并维持存储文件夹。不要改动快照View的存储文件夹的文件系统许可。