为了账号安全,请及时绑定邮箱和手机立即绑定

每个开发人员应该知道哪些基本的ClearCase概念?

/ 猿问

每个开发人员应该知道哪些基本的ClearCase概念?

大话西游666 2019-06-04 17:26:08

每个开发人员应该知道哪些基本的ClearCase概念?

每个开发人员都应该知道的ClearCase版本控制系统的核心概念是什么?



查看完整描述

3 回答

?
偶然的你

岩心概念?

  • 集中(复制)VCSClearCase位于集中式VCS世界(一个或几个“集中式”Repos或VOBS版本对象库-每个开发人员必须访问提交)和分布式VCS世界之间。
    但它还支持“复制”模式,允许您在远程站点(多站点ClearCase)复制回购,发送三角洲,并管理所有权。(但附带的许可费相当昂贵)
    这不是真正的“分散”模型,因为它不允许并行。并发进化:分支在一个VOB或另一个VOB中掌握;您只能签入主VOB,因为在那里已经掌握了分支,尽管您可以在任何副本上对任何分支进行可读性访问。

  • 线性版本存储*每个档案和目录具有线性历史;它们之间没有像DAGVCS那样的直接关系(有向无圈图)将文件的历史链接到提交的目录中的一个目录。
    这意味着

    • 如果其图的一个节点与不同提交的节点具有相同的“id”,则不需要进一步研究:所有子图都保证是相同的。
    • 两个分支的合并实际上是DAG中两个节点内容的合并:递归的,非常快速地找到一个共同的祖先)
    • 当比较两个提交时,必须比较所有文件和目录的列表才能找到增量,因为提交不是跨文件或目录的原子性的,这意味着组成逻辑增量的所有文件的所有更改都没有一个名称。
    • 这也意味着合并必须找到共同的基础贡献者(并不总是和一个共同的祖先相同)通过历史探索(见下一点)。

      (GIT处于这一范围的另一端,既分散又面向DAG:

ALT文本http:/publib.boulder.ibm.com/InfoCenter/c螯合/v7r0m0/Topic/com.ibm.rital.ClearCase.hlp.doc/cc_main/映像/merg_base_contrib.gif

  • 3路合并为了合并两个版本,ClearCase必须在它们的线性历史中找到一个基于公共的贡献者,这可以是复杂版本树相当长(支部/分处.)ClearCase合并命令合并文件或目录,但它不是递归的。它只影响一个单独的文件,或者一个没有它的文件的目录(ct findmerge是递归的)

  • 以文件为中心(相对于其他最近更以存储库为中心的VCS):这意味着提交是一个文件,而不是“一组修改的文件”:事务位于文件级别。多个文件的提交不是原子的。
    (几乎每一个人现代工具是“以存储库为中心的”,具有原子提交事务,但是第一代系统(如RCS、SCCS、CVS和其他大多数旧系统)没有这种特性。

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

(创建两个大小和内容相同的文件,它们将在Git中获得相同的id-一个SHA 1密钥-只在Gitrepo中存储一次!在ClearCase中并非如此。
另外,如果两个路径和名称相同的文件在两个不同的分支中创建,它们的id是不同的,这意味着这两个文件永远不会合并:它们被称为“邪恶双胞胎")

  • 分支机构是一流的公民。大多数VCS都认为一个分支和一个标记是相同的:历史上一个新的线性历史可以从其中生长(分支)或附加描述(标记)的一个点。
    ClearCase的情况并非如此,其中分支是引用版本号的一种方式。任何版本号从0开始(只在ClearCase中引用)到1、2、3,等等。每个分支都可以包含一个新的版本号列表(再次显示0、1、2、3)。
    这与其他系统不同,在其他系统中,版本号是唯一的,并且总是在增长(比如SVN中的修订版),或者只是唯一的(比如Git中的SHA 1键)。

  • 路径存取要访问某个文件/目录的特定版本,您需要知道它的扩展路径(由分支和版本组成)。它被称为“扩展路径名”:myFile@@/main/subBranch/Version.

(git是指通过id-基于sha 1含量一份文件]。因此,它是“id访问”或“id-引用”。
对于ClearCase,id指的是“元素”:目录或文件,不管它的版本是什么。

  • 悲观锁和乐观锁*(ClearCase中的保留或非保留签出):即使是悲观锁(保留签出)也不是真正的悲观锁,因为其他用户仍然可以签出该文件(尽管处于“非保留模式”):他们可以更改该文件,但必须等待第一个用户提交他的文件(签入)或取消请求。然后他们将合并相同文件的签出版本。
    (注意:“保留”结帐可以解除其锁定,并由所有者或管理员进行无保留。)

  • 廉价分支*分支并不触发所有文件的副本。它实际上不会触发任何东西:任何文件,而不是签出,都将留在原来的分支中。只有修改后的文件才会将其新版本存储在声明的分支中。

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

  • 本地或网络工作区访问:

    • 本地工作区是通过签出到硬盘驱动器(快照视图的“更新”)。
    • 网络工作区通过动态视图,将通过网络访问的版本文件和目录(没有本地副本、即时访问)和本地文件(已签出的文件或私有文件)结合在一起。远程(版本)和本地(私有)文件的组合允许动态视图显示为一个典型的硬盘驱动器(而实际上,任何“写”的文件都存储在关联的视图存储中)。
  • 集中驱逐储存:[view]存储是为了保存一些数据,并避免与中央引用进行部分或任何通信。
    工作区可以有:

    • 散乱的仓库:就像

      .svn

      整个地方的子目录
    • 集中式存储:就像ClearCase中的视图存储一样,它们包含有关视图显示的文件的信息,并且该存储对于视图是唯一的。
    • 驱逐的存储:存储不是视图/工作区本身的一部分,而是可以位于计算机的其他地方,甚至可以位于LAN/WAN之外。

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

  • 面向元数据

    :任何“键值”都可以附加到文件或目录中,但这两个数据本身并不是历史化的:如果值发生变化,它将重写旧值。

(这意味着该机制实际上比SVN的“属性”系统更弱,在该系统中,属性可以具有历史;
另一方面,git对元数据不太感兴趣)

  • 系统保护

    :与文件/目录或存储库相关的所有者和权限基于底层系统的权限管理。ClearCase中没有应用程序帐户,用户组直接基于Windows或Unix现有组(这在异构环境中是相当有挑战性的,有Windows客户端和UnixVOB服务器!)

(SVN更像是“基于服务器的”保护,Apache服务器可以获得第一级保护,但必须用钩子完成才能获得更好的权限。
GIT没有直接的权限管理,在存储库之间推拉时必须由钩子控制)

  • 有钩任何ClearCase动作都可以是一个叫做触发器的钩子的目标。它可以是手术前或手术后。

  • CLI管理清除工具是命令行接口,可以从它进行所有操作。


查看完整回答
反对 回复 2019-06-04
?
呼如林

ClearCase是一个可以使用的野兽。速度慢,价格昂贵。我为应对使用CC所做的一些事情是:

  1. 当你登记入住时,一定要提出好的意见。
  2. 使用通用配置规范,不要经常更改它。
  3. 不要尝试通过VPN或慢网络连接使用CC。
  4. 启动时关闭加载CC医生。
  5. 不要将文件移动到不同的目录。
  6. 请安排每个文件至少2分钟进行签入。
  7. 快照视图比较慢,但是动态视图比较慢。
  8. 养成早期和经常签入的开发习惯,因为保留的文件和合并是痛苦的。
  9. 默认情况下,让所有开发人员签出无保留的文件。


查看完整回答
反对 回复 2019-06-04
?
慕村9548890

我们使用CC已经十五年多了。它有很多优点。

我们所有的开发都是在分支上完成的;我今天创建了几个分支,用于几组不同的更改。当我签入分支时,我有一位同事来检查这些更改,然后将其合并回/main/最新-这恰好是我的工作需要做的地方。如果是因为在分支上发布了更早的版本,就不会更难了。

临时分支的合并是完全自动的;在我检查这些文件时,没有人更改过我所处理的文件。尽管默认情况下,签出是保留的(锁定),但是您可以在以后取消签出,或者创建未保留的签出。当更改花费多天时间时,我的临时分支与主分支的重新同步很容易,而且通常是自动的。MergeTool是可以的;对我来说最大的问题是我的服务器机器离我的办公室(或家)大约1800英里,所以X在那遥远的地方有点慢(但不能忍受)。我没有使用过更好的合并工具,但这可能并不能说明什么,因为我没有使用过任何其他的图形合并工具。

视图(动态视图)在我们的设置上是快速的。我没有使用快照视图,但是当我能够帮助它时,我就不会在Windows上工作(我们的团队在Windows上使用快照视图;我不清楚为什么)。我们有复杂的分支系统,但是主要开发是在/main/最新完成的,发布工作是在一个分支上完成的。在GA之后,维护工作将在特定于发行版的分支上完成,并将其合并到/main/最新(通过任何中间版本)。

CC确实需要优秀的管理员-我们有他们,而且幸运地做到了这一点。

CC的使用并不简单,尽管目前,我发现对于那些没有使用它的人来说,“git”和CC一样令人望而生畏。但是基本原理是相同的-签出、更改、签入、合并、分支等等。目录可以分叉-小心-当然也是版本控制的。这是无价之宝。

我什么时候都没看到办公室从CC转过来。


嵌入版本号-好还是坏?

我写道:

我对CC最大的问题是它没有将版本号嵌入源文件-GIT也有一个问题,AFAICT。我完全明白原因,但我不确定我是否喜欢放弃这种可追踪性。因此,在我的大部分个人工作中,我仍然使用RCS(甚至不使用CVS)。有一天,我可能会切换到GIT,但这将是一个震动,它将需要大量的工作来重新配置(SCCS和)RCS周围的发布系统。

@vonc在答复中指出:

我们一直认为这种做法是邪恶的(将元数据信息与数据混合在一起),引入了“合并地狱”。另见如何在Java文件中获取ClearCase文件版本..当然,您可以使用触发器替换RCS关键字(ClearCase手册:Checkin触发器示例)如果您使用适当的合并管理器.

这次讨论暴露了几个问题,它们都混合在一起。我的观点近乎过时,但背后有一个理由,我要花时间把它们写下来(生活搞砸了-可能需要几个编辑才能完成)。

背景技术

我早在1984年就学会了SCCS,大约在RCS发布的时候(我相信,1983年),但SCCS在我的机器上,互联网充其量才刚刚起步。我在90年代中期不情愿地从SCCS转到RCS,因为SCCS的日期格式多年来使用两位数,而且不清楚SCCS是否会在时间上普遍固定(确实如此)。在某些方面,我不像SCCS那样喜欢RCS,但它有一些优点。商业上,我的雇主使用SCCS直到1995年年中,但他们开始转换到Atria ClearCase从1994年初,解决一个单独的产品集一次。

早期的ClearCase实验与触发器-并合并地狱

我们的项目后来迁移了,那时已经有了一些CC方面的经验。部分原因是我坚持这样做,我们通过签入触发器将版本控制信息嵌入源文件中。这种情况持续了一段时间-但只持续了一段时间-因为,正如冯克所说,它导致了地狱的合并。问题是,如果带有标记/main/分支1/N的版本与公共基础版本/main/B中的/main/M合并,则文件的提取版本包含在每个版本中编辑的一行-冲突。这种冲突必须手动解决,而不是自动处理。

现在,SCCS有ID关键字。ID关键字采用两种格式,一种用于正在编辑的文件,另一种用于未经编辑的文件:

Edit         Non-Edit
%I%          9.13
%E%          06/03/09
%Z%          @(#)
%M%          s.stderr.c

如果尝试对SCCS文件的可编辑版本进行3路合并(使用%x%表示法),然后,包含元数据的行将不会发生冲突,除非您更改了这些行上的元数据(例如,通过将美国式%D%日期更改为英国样式%E%Date-SCCS不支持ISO风格的2009-03-15日期作为标准)。

RCS还有一个关键字机制,关键字也采用两种格式,一种是用于尚未插入RCS的文件,另一种是用于具有:

Original       After insertion
$Revision$     $Revision: 9.13 $
$Date$         $Date: 2009/03/06 06:52:26 $
$RCSfile$      $RCSfile: stderr.c,v $

区别在于关键字后面的‘$’和‘:’、空格、文本、空格和最后‘$’之间的区别。我还没有完成足够的与RCS的合并,以确定它对关键字信息所做的事情,但我注意到,如果它将扩展的和“收缩的”符号视为等价的(不管扩展的材料的内容如何),那么合并就可以在没有冲突的情况下进行,在合并的输出中留下收缩的符号,在签入后检索结果文件时,将适当地展开该文件。

ClearCase问题是缺少适当的合并管理器。

正如我在讨论SCCS和RCS时指出的那样,如果3路合并是以正确的(收缩或可编辑)格式处理关键字,那么就没有合并冲突。

CC的问题(显然,CC的实施者不同意)是因为它缺乏一个处理关键字的系统,因此也缺少一个合适的合并管理器。

如果有一个处理关键字的系统和一个适当的合并管理器,那么:

  • 系统将自动将元数据嵌入到适当标记处的文件中。
  • 在合并时,系统将认识到,与元数据标记的行不会发生冲突,除非标记发生了不同的变化-它将忽略元数据内容。

这样做的缺点是,它需要一个特殊的差异工具来识别元数据标记并对它们进行特殊处理,或者需要将输入给差异工具的文件规范化(元数据标记被简化为中性形式-在RCS和SCCS术语中,$关键字$或%K%)。我确信,这一点额外的工作是为什么它不支持,这是我一直觉得是短视在如此强大的系统。我对RCS或SCCS符号没有特别的依附-SCCS符号在某些方面更容易处理,但它们本质上是等价的-任何等效的表示法都可以使用。

为什么我仍然认为文件中的元数据是好的?

我喜欢在源代码中包含元数据,因为我的源代码(相对于我雇主的源代码)分布在宙斯盾源代码控制系统。也就是说,它主要是开源的-我把它提供给所有的人。如果有人报告了文件中的问题,特别是他们修改过的文件中的问题,我认为知道他们从哪里开始是有帮助的,这是由源文件中的原始元数据表示的。

在这里,SCCS比RCS有一个优势:SCCS关键字的扩展形式与常规文本无法区分,而RCS关键字仍然看起来像关键字,所以如果其他人将材料导入到他们自己的RCS存储库中,它们的元数据将替换我的元数据,SCCS不以相同的方式发生的问题(另一个人必须做工作来覆盖元数据)。

因此,即使有人从我的源代码中提取一部分并对其进行修改,它通常也有足够的标签来识别它的来源,而不是让我来推测它是基于哪个版本的。而这反过来又使我们更容易看出问题的哪些部分是我造成的,哪些部分是我造成的。

现在,在实践中,开放源码的工作方式,人们并不像您想象的那样迁移代码。他们倾向于严格遵守发布的版本,因为当下一次正式发布时,偏离太昂贵了。

我不知道您应该如何确定源自您的工作并自那以后已经修改的源代码的基本版本。然而,找到正确的版本似乎是关键,如果代码中有指纹,那就更容易了。

因此,这是对为什么我喜欢将版本信息嵌入源文件的适度总结。这在很大程度上是历史性的-SCCS和RCS都是这样做的,我喜欢他们这样做。这可能是古代的遗物,在DVCS时代被禁止告别的东西。但我还没有完全相信这一点。然而,可能需要更多的文章来解释我的发布管理机制的来龙去脉,看看我为什么要这么做。

推理的一个方面是,关键文件,例如‘stderr.c’和‘stderr.h’,基本上被我的所有程序使用。当我发布一个使用它的程序时,我只需确保我有最新的版本-除非界面更改需要返回版本。我已经有一段时间没有遇到这个问题了(我在2003年进行了系统重命名;这导致了一些过渡性问题,但是Perl脚本允许我很容易地实现重命名)。我不知道有多少程序使用这段代码-大概在100到200之间是一个合理的猜测。今年的一系列更改(9.x版本)仍然有些推测性;我还没有最终决定是否保留它们。它们也是实现的内部部分,不影响外部接口,所以我现在还不需要下决心。我不知道如何用git来处理这件事。我不想把库代码构建成一个库,在构建我的软件之前必须安装它-这对我的客户来说太麻烦了。因此,每个程序将继续分发一个库代码的副本(一个不同类型的繁重),但只有程序所需的库代码,而不是整个库。我为每个程序选择使用库函数的程序。因此,我不会导出一个完整的子树;实际上,涵盖库代码中最后一次更改的提交通常与涵盖程序中最后更改的提交完全无关。我甚至不确定GIT是否应该对库使用一个存储库,对于使用它的程序使用另一个存储库,还是使用一个通用的更大的存储库。在我真正明白这一点之前我不会迁移到GIT。

好吧-别胡说八道了。我所拥有的对我来说是有用的,但并不一定适合每个人。它并没有对VCS提出特别的要求,但它确实需要嵌入在文件中的版本元数据,而CC和Git以及(我认为)SVN对此有问题。这可能意味着我是那个有问题的人-为逝去的过去争分夺秒。但我珍视过去所能提供的。(我可以不使用它,因为我的大部分代码都不是分支的。我不知道分支会有多大的区别。)


查看完整回答
反对 回复 2019-06-04

添加回答

回复

举报

0/150
提交
取消
意见反馈 邀请有奖 帮助中心 APP下载
官方微信