clearcase - 每个开发人员都应该知道的基本 clearcase 概念是什么？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果你觉得这个问题可以改进并可能重新打开，visit the help center 寻求指导。




8年前关闭。










锁定。这个问题及其答案是 locked 因为这个问题是题外话但具有历史意义。它目前不接受新的答案或互动。








每个开发者都应该知道的 Clearcase 版本控制系统的核心概念是什么？

Answer 1

核心 概念？

集中式(-复制)VCS :ClearCase 介于集中式 VCS 世界(一个或多个“集中式”存储库或 VOBS 之间。每个版本对象都必须访问 VCS，并且 VCS 世界必须提交)
但它还支持“复制”模式，允许您在远程站点 (MultiSite ClearCase) 中复制存储库、发送增量和管理所有权。 (虽然附带的许可费相当高)
这不是一个真正的“去中心化”模型，因为它不允许并行并发演化:分支在一个 VOB 或另一个 VOB 中掌握；您只能为在那里掌握的分支 checkin 主 VOB，尽管您对任何副本上的任何分支都具有只读访问权限。

线性版本存储 :每个文件和目录都有一个线性历史；它们之间没有直接关系，如 DAG VCS ( Directed Acyclic Graph )，其中文件的历史记录链接到链接到提交的目录之一。
这意味着

当您比较两次提交时，您必须比较所有文件和目录的列表以找到增量，因为提交不是跨文件或目录的原子，这意味着对构成的所有文件的所有更改没有单一名称一个逻辑增量。

这也意味着 merge 必须找到一个共同的 0x2518122133414 必须找到一个共同的 0x2518122133414(不总是通过相同的祖先来探索相同的历史点)。

(Git 处于该范围的另一端，既是去中心化的，又是面向 DAG 的:

如果其图的节点与不同提交的节点具有相同的“id”，则不必进一步探索:所有子图都保证相同

两个分支的合并实际上是一个 DAG 中两个节点的内容的合并:递归并且非常快速地找到一个共同的祖先)

base contributor

3-way merging :要合并两个版本，ClearCase 必须在它们的线性历史中找到一个共同的基于贡献者，可以是 0x2518111222-subbra,basic-subbra,subnch-subbra, 和alt text http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/topic/com.ibm.rational.clearcase.hlp.doc/cc_main/images/merg_base_contrib.gif 命令合并文件或目录，但不是递归的。它只影响单个文件，或没有文件的单个目录(ct findmerge 是递归的)

以文件为中心 (与最近的另一个以存储库为中心的 VCS 相反):这意味着提交是逐个文件的，而不是“一组修改过的文件”:事务处于文件级别。多个文件的提交不是原子的。
(几乎所有其他现代工具都是“以存储库为中心”，具有原子提交事务，但第一代系统如 RCS、SCCS、CVS 和大多数其他旧系统没有该功能。)

id-managed :每个文件和目录都有一个唯一的id，这意味着它们可以随意重命名:它们的历史不会改变，因为id仍然是“元素”。此外，目录将在其历史记录中检测到文件的任何添加/抑制。当文件被“删除”( rmname )时，它并不知道:只通知目录并在其历史记录中创建一个新版本，其中包含不包括删除文件的子元素列表。

(创建两个具有相同大小和内容的文件，它们将在 Git 中获得相同的 id——一个 SHA1 key ——并且只会在 Git 存储库中存储一次!在 ClearCase 中并非如此。
另外，如果在两个不同的分支中创建了两个具有相同路径和名称的文件，它们的 id 不同意味着这两个文件将永远不会合并:它们被称为“邪恶双胞胎”)

分支是一等公民 :大多数 VCS 认为分支和标签是相同的:历史中的一个点，新的线性历史可以从中生长(分支)或从哪里开始(附加描述)。
对于 ClearCase 而言并非如此，其中分支是引用版本号的一种方式。任何版本号都从 0(仅在 ClearCase 中引用)开始到 1、2、3 等等。每个分支都可以包含一个新的版本号列表(再次是 0、1、2、3)。
这与版本号唯一且始终在增长(如 SVN 中的修订版)或只是唯一的(如 Git 中的 SHA1 key )的其他系统不同。

path-accessed :要访问某个版本的文件/目录，您需要知道其扩展路径(由分支和版本组成)。它被称为“扩展路径名”: myFile@@/main/subBranch/Version 。

(Git 确实通过 id——基于 SHA1 的——:版本 [或提交]、树 [或目录的版本] 和 blob [或文件的版本，或者更确切地说是文件的内容] 来指代所有内容。所以它是“id-accessed”或“id-referenced”。
对于 ClearCase，一个 id 指的是一个“元素”:一个目录或一个文件，不管它的版本是什么。)

悲观锁和乐观锁 :(ClearCase 中的保留或非保留结帐):即使是悲观锁(由于其他用户仍然无法保留，因此在非保留模式下结帐) :他们可以更改它，但必须等待第一个用户提交他的文件( checkin )或取消请求。然后他们将合并同一文件的结帐版本。
(注意:“保留”结帐可以释放其锁定并由所有者或管理员取消保留)

廉价分支 :分支不会触发所有文件的副本。它实际上什么也不会触发:任何未结帐的文件都将保留在其原始分支中。只有修改过的文件才会将它们的新版本存储在声明的分支中。

平面文件存储 :VOB 以专有格式存储，包含简单文件。这不是一个具有简单查询语言的数据库。

本地或网络工作区访问 :

本地工作区通过结帐到硬盘驱动器(快照 View 的“更新”)。

网络工作空间是通过动态查看，结合了通过网络访问的版本化文件和目录(无本地复制，即时访问)和本地文件( checkout 的文件或私有(private)文件)。远程(版本化)和本地(私有(private))文件的组合允许动态 View 看起来像一个经典的硬盘驱动器(而实际上任何“写入”的文件都存储在相关的 View 存储中)。

集中驱逐存储 : [查看] 存储是为了保存一些数据并避免与中央引用进行一些或任何通信。
工作区可以有:

一个分散的存储:像.svn 子目录到处都是

集中式存储:与 ClearCase 中的 View 存储一样，它们包含有关 View 显示的文件的信息，并且该存储对于 View 来说是唯一的。

驱逐存储:存储不是 View /工作区本身的一部分，但可以位于计算机上的其他位置，甚至位于 LAN/WAN 外部

(Git 本身没有“存储”。它的 .git 实际上是所有的存储库!)

面向元数据 :任何“键值”都可以附加到文件或目录，但是这对数据本身没有历史记录:如果值发生变化，它会覆盖旧值。

(意味着该机制实际上比SVN的“属性”系统弱，其中属性可以有历史；
另一端的 Git 不太热衷于元数据)

基于系统的保护 :所有者和与文件/目录或存储库相关的权限基于底层系统的权限管理。 ClearCase 中没有适用的账号，用户组直接基于 Windows 或 Unix 现有组(这在异构环境中非常具有挑战性，有 Windows 客户端和 Unix VOB 服务器!)

(SVN更像是“基于服务器”的保护，Apache服务器可以获得第一级保护，但必须用钩子(Hook)完成才能拥有更细粒度的权限。
Git 没有直接的权限管理，在仓库之间的推送或拉取过程中必须由钩子(Hook)控制)

可用钩子(Hook) :任何 ClearCase 操作都可以是钩子(Hook)的目标，称为触发器。它可以是前操作或后操作。

CLI 管理 :cleartool 是命令行界面，可以从中进行所有操作。