每个开发人员都应了解什么基本的casecase概念？ [英] What are the basic clearcase concepts every developer should know?

问题描述

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

What are the core concepts of the Clearcase version control system every developer should know?

推荐答案

核心 概念？

Core concepts?

• 集中式（复制）VCS ：ClearCase位于集中式VCS世界的中间（一个或几个集中式存储库或VOBS-版本对象库-每个开发人员都必须具有提交权限）和分布式VCS世界。
  
  但它还支持复制模式，允许您在远程站点（MultiSite ClearCase）中复制存储库，发送增量，并管理所有权。 （但附带的许可费相当高）。
  
  这不是真正的去中心化模型，因为它不允许并行的 concurrent 演进：分支是掌握在一个或另一个VOB中；尽管您可以只读访问任何副本中的任何分支，但是您只能签入主VOB才能访问那里的分支。

• centralized(-replicated) VCS: ClearCase is halfway between the centralized VCS world (one or several "centralized" repos or VOBS - Version Object Bases - every developer must access to commit) and the distributed VCS world.
  But it also supports a "replicated" mode allowing you to replicate a repo in a distant site (MultiSite ClearCase), sending deltas, and managing ownership. (the license fees attached with that is quite steep though)
  This is not a true "decentralized" model, since it is does not allow for parallel concurrent evolutions: The branches are mastered in one VOB or another; you can only check-in to the master VOB for the branches mastered there, though you have readonly access to any branch at any replica.

linear版本存储：每个文件和目录具有线性历史记录；它们之间没有直接关系，例如DAG VCS（有向无环图），其中文件链接到与提交链接的目录之一。

这意味着

linear version storage: each file and directory has a linear history; there is no direct relationship between them like the DAG VCS (Directed Acyclic Graph) where the history of a file is linked to the one of a directory linked to a commit.
That means

• ，您必须比较所有文件和目录的列表以找到增量，因为提交不是跨文件或目录的原子操作，这意味着组成逻辑增量的所有文件的所有更改都没有统一的名称。
  

• 这也意味着 合并 必须找到通用的 基本贡献者 （并不总是与共同祖先相同）（请参阅下一点）。

• when you compare two commits, you have to compare the list of all files and directories to find the delta, since commits are not atomic across files or directories, meaning there is no single name for all the changes to all the files that make up a logical delta.

• That also means a merge must find a common base contributor (not always the same as a common ancestor) through history exploration (see next point).

（Git在另一端）分散且面向DAG的频谱：

(Git is at the opposite end of that spectrum, being both decentralized and DAG-oriented:

• 如果其图的节点与a的节点具有相同的 id不同的提交，不必进一步探讨：保证所有子图都是相同的


• 两个分支的合并实际上是DAG中两个节点内容的合并：递归且非常容易找到共同祖先）

替代文字http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/topic/com.ibm.rational.clearcase.hlp.doc/cc_main/images/merg_base_contrib.gif

• 三向合并：合并两个版本，ClearCase必须在其线性历史记录中找到一个基于共同贡献者，可以是对于复杂的版本树来说相当长（分支/子分支/ sub-sub /分支，...）和基本的 ClearCase merge 命令可合并文件或目录，但不是递归的。它仅影响单个文件或不包含其文件的单个目录（ ct findmerge 是递归的）

• 3-way merging: to merge two versions, ClearCase must find a common based contributor in their linear history, which can be fairly long for complex version tree (branch/sub-branch/sub-sub/branch, ...), and the basic ClearCase merge command merges a file or directory, but it is not recursive. It only affects a singe file, or a single directory without its files (ct findmerge is recursive)

以文件为中心（相对于最近的其他VCS，以存储库为中心）：这意味着提交是逐文件进行的，而不是已修改文件集：事务处于文件级别。几个文件的提交不是原子的。

（几乎所有其他 modern 工具都是以存储库为中心的，具有原子的提交事务，但是第一代系统如RCS，SCCS ，CVS和大多数其他较旧的系统都没有该功能。）

file-centric (as opposed to the other recent VCS more repository centric): that means the commit is file by file, not "set of modified files": the transaction is at the file level. A commit of several files is not atomic.
(Almost every other modern tool is "repository centric", with an atomic commit transaction, but first-generation systems like RCS, SCCS, CVS, and most other older systems do not have that feature.)

id-managed ：每个文件和目录都有一个唯一ID，表示可以随意重命名：由于ID保留为元素，因此它们的历史记录不会更改。另外，目录将在其历史记录中检测到文件的任何添加/压缩。当文件被删除（ rmname ）时，它不知道：仅通知目录并在其历史记录中创建一个新版本，并列出子目录。

id-managed: each file and directory has a unique id, meaning they can be renamed at will: their history will not change since the id remains for the "element". Plus a directory will detect in its history any addition/suppression of file. When a file is "removed" (rmname), it does not know it: only the directory is notified and creates a new version in its history, with a list of sub-elements not including the file removed.

（创建两个具有相同大小和内容的文件，它们将得到相同的元素Git中的id（SHA1密钥），将仅在Git存储库中存储一次；在ClearCase中不是这样。
另外，如果在两个不同的分支中创建了具有相同路径和名称的两个文件，它们的ID不同意味着这两个文件将永远不会合并：它们被称为 邪恶双胞胎）

(Create two files with the same size and content, they will get the same id in Git -- a SHA1 key -- and will be stored only once in the Git repo! Not so in ClearCase.
Plus, If two files with the same path and name are created in two different branches, their id being different means those two files will never be merged: they are called "evil twins")

• 分支是一等公民：大多数VCS都将分支和标签视为相同：历史中的单个点，新的线性历史可以从该点增长（分支）或从何处增长
  
  对于ClearCase而言并非如此，其中的分支是引用版本号的一种方式。任何版本号都从0（在ClearCase中仅引用）到1、2、3等开始。每个分支可以包含一个新的版本号列表（再次为0、1、2、3）。
  
  这与版本号唯一且始终在增长的其他系统（例如SVN中的修订版）不同。 ，或者只是唯一的（例如Git中的SHA1键）。

• branches are first-class citizens: most VCS consider a branch and a tag as the same: a single point in the history from which a new linear history can grow (branch) or from where a description is attached (tag).
  Not so for ClearCase, where a branch is a way to reference a version number. Any version number starts at 0 (just referenced in ClearCase) to 1, 2, 3, and so on. Each branch can contain a new list of version numbers (0, 1, 2, 3 again).
  This is different from other systems where the version number is unique and always growing (like the revisions in SVN), or is just unique (like the SHA1 keys in Git).

路径访问：访问特定版本的文件/目录，您需要知道其扩展路径（由分支和版本组成）。它称为扩展路径名： myFile @@ / main / subBranch / Version 。

path-accessed: to access a certain version of a file/directory, you need to know its extended path (composed of branches and versions). It is called an "extended path name": myFile@@/main/subBranch/Version.

（Git确实通过id引用所有内容-基于SHA1的-：版本[或提交]，树[或目录的版本]和blob [或文件的版本，或

对于ClearCase，id表示元素：而不是文件的 ]。目录或文件，无论其版本是什么。）

(Git does refer to everything through id -- SHA1-based --: version [or commit], tree [or version of a directory] and blob [or version of a file, or rather of a content of a file]. So it is "id-accessed" or "id-referenced".
For ClearCase, an id refers to an "element": a directory or a file, whatever its version is.)

• 悲观锁和乐观锁 ：（在ClearCase中保留或不保留签出）：即使是悲观锁（保留签出）也不是真正的悲观锁，因为其他用户仍然可以签出该文件（尽管处于未保留模式）：他们可以更改它，但必须等待第一个用户提交他的文件（签入）或取消请求。然后，他们将合并同一文件的签出版本。
  
  （注意：保留签出可以释放其锁，并且可以由所有者或管理员取消保留）。

• both pessimistic lock and optimistic lock: (reserved or unreserved checkouts in ClearCase): even a pessimistic lock (reserved checkout) is not a true pessimistic one, since other users can still checkout that file (albeit in "unreserved mode"): they can change it but will have to wait for the first user to commit his file (checkin) or cancel the request. Then they will merge their checkout version of that same file.
  (Note: a "reserved" checkout can release its lock and be made unreserved, either by the owner or the administrator)

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

cheap branching: a branch does not trigger a copy of all files. It actually triggers nothing: any file not checkout will stay in its original branch. Only modified files will have their new versions stored in the declared branch.

平面文件存储：VOB存储在具有简单文件的专有格式。这不是具有简单查询语言的数据库。

flat-file storage: the VOBs are stored in a proprietary format with simple files. This is not a database with an easy query language.

本地或网络工作区访问权限：

• 本地工作区通过检出到硬盘驱动器（快照视图的更新）。


• 网络工作区是通过动态视图，将通过网络（没有本地副本，即时访问）和本地文件（已检出文件或私有文件）的版本化文件和目录组合在一起。远程（版本化）文件和本地（私有）文件的组合使动态视图看起来像传统的硬盘驱动器（而实际上任何写入的文件都存储在关联的视图存储中）。

集中的驱逐出境存储：[视图]那里的存储用于保留一些数据并避免与中央参考进行某些或任何通信。 br>
a工作区可以具有：

centralized deported storage: [view] storage is there to keep some data and avoid some or any communication with the central referential.
a workspace can have:

• 分散的存储空间：例如 .svn 子目录无处不在


• 集中存储：类似于ClearCase中的视图存储，它们包含有关视图显示的文件的信息，并且该存储对于视图是唯一的。


• 逐出存储：该存储本身不是视图/工作区的一部分，但可以位于计算机上的其他位置，甚至可以位于LAN / WAN的外部

• a scattered storage: like the .svn subdirectories all over the place
• a centralized storage: like the view storage in ClearCase, they contain information about the files displayed by the view, and that storage is unique for a view.
• a deported storage: the storage is not part of the view/workspace itself, but can be located elsewhere on the computer or even outside on the LAN/WAN

（Git本身没有存储。它的 .git 实际上是所有存储库ry！）

(Git has no "storage" per se. Its .git is actually all the repository!)

• 面向元数据：任何键值都可以附加到文件或目录，但是这对数据本身并不是历史记录：如果值更改，它将覆盖旧值。

• meta-data oriented: any "key-value" can be attached to a file or a directory, but that couple of data is not historized itself: if the value changes, it overrides the old value.

（表示机制实际上比SVN的属性系统弱，在SVN中，属性可以有历史；

另一端的Git不太热衷于元数据）

(meaning the mechanism is actually weaker than the "properties" system of SVN, where properties can have an history;
Git on the other end is not too keen on meta-data)

• 基于系统的保护：所有者和与文件/目录或存储库相关联的权限基于基础系统的权限管理。 $ li $ $ b $ ClearCase中没有适用的帐户，用户组直接基于Windows或Unix现有组（这在具有Windows客户端和Unix VOB服务器的异构环境中是一个很大的挑战！）
b

• system-based protection: the owner and the rights associated with a file/directory or repositories are based on the rights-management of the underlying system. There is no applicative account in ClearCase, and the group of users are directly based on the Windows or Unix existing group (which is quite challenging in an heterogeneous environment, with Windows clients and a Unix VOB server!)

（SVN更像是基于服务器的保护，Apache服务器可以得到第一级保护，但必须使用钩子才能完成，以获得更好的保护

Git没有直接的权限管理，必须在存储库之间的推入或拉出过程中由钩子控制）。

(SVN is more like "server-based" protection, where the Apache server can get a first level of protection, but must be completed with hooks to have a finer grain of rights.
Git has no direct rights management and must be controlled by hooks during push or pull between repositories)

• 可用的挂钩：任何ClearCase动作都可以作为挂钩的目标，称为触发器。

• hooks available: any ClearCase action can be the target of a hook, called trigger. It can be a pre or post operation.

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

CLI managed: cleartool is the Command Line Interface from which all actions can be made.

这篇关于每个开发人员都应了解什么基本的casecase概念？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！