SVN用户学习ClearCase的快速方法 [英] Quick way for SVN user to learn ClearCase

查看:61
本文介绍了SVN用户学习ClearCase的快速方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

到目前为止,我一直在使用SVN,从开发人员的角度来看,现在需要快速使用ClearCase。有什么好的资源吗?谢谢。

So far I've been using SVN, and now is in need to pick up ClearCase quickly, from developer's perspective. Is there any good resource for this? Thanks.

-添加-

SVN的概念/术语(例如存储库,工作副本,主干,分支,标签,签出,提交,更新,还原)与CC?根据初步阅读,我得出以下结论。

-- add on --
Is there a map between SVN's concepts/terminologies (i.e. repository, working copy, trunk, branch, tag, checkout, commit, update, revert) with CC's? Base on initial reading I came out with the following.

存储库=> VOB?

工作副本=>快照视图?

中继=> ??

分支=>集成流?开发流?

标签=>标签?是基线吗?

从repo作为工作副本检出=>从VOB作为快照视图检出?

从工作副本提交到repo =>从快照视图检入到VOB?

更新=>恢复基准吗?

恢复=> ??

? =>交付

Repository => VOB?
Working copy => Snapshot view?
Trunk => ??
Branch => Integration stream? development stream?
Tag => Label? Baseline?
Checkout from repo as working copy => Checkout from VOB as snapshot view?
Commit from working copy into repo => Checkin from snapshot view into VOB?
Update => Rebase?
Revert => ??
?? => Deliver

AFAIK CC具有自己独特的概念,因此我无法告诉最近的地图。

AFAIK CC has its own unique concepts, thus I can't tell the nearest map.

推荐答案

您可以先阅读我的SO答案:

You can start by reading my SO answers:

  • What are the basic clearcase concepts every developer should know?
  • ClearCase advantages/disadvantages
  • How to Leverage Clearcase’s features

您需要了解的两个主要区别是:

The two main differences you need to be aware of is:


  • ClearCase以文件为中心,而不是以存储库为中心,这意味着您将获得只读文件,需要逐一签出才能修改Fy,(并且您也一一提交(签入)):此处没有全局工作区修订

  • ClearCase is file-centric, not repository centric, meaning you get read-only files you need to checkout one-by-one to be able to modify, (and you "commit" (checkin) one by one as well): no global workspace revision here

ClearCase将分支视为真实元数据,而不是带有便宜副本的目录 :其中没有带有分支名称的目录。

ClearCase consider branching as true metadata, and not as a "directory" with a cheap copy in it: there is non "directory" with the name of a branch in it.

话虽这么说:


  • 存储库=> VOB

    是:VOB只是存储库的另一个术语(基于版本的对象)。它不是SQL数据库,而是旧的Atria平面文件库。

  • Repository => VOB:
    Yes: VOB is just another term for repo (Versioned Object base). It is not a SQL database, but an old Atria flat files base.

工作副本=>快照视图?

快照视图是工作副本中最接近的访问机制,因为它会将文件复制到硬盘上。

动态视图实现了对工作副本的相同访问。 ..而无需在硬盘上复制任何内容,这对于快速咨询很有用。

Working copy => Snapshot view?
Snapshot view is the closest access mechanism from a working copy, since it copies files on your hard drive.
Dynamic view achieve the same access to a working copy... without copying anything on your hard drive, which is interesting for quick consultation purpose.

Trunk => ??

main :这是ClearCase中的主要分支(ClearCase中的每个元素-文件或目录都位于主上至少有一个版本),但实际上除了选择的一个分支外,没有任何中继。

Trunk => ??
"main": that is the main branch in ClearCase (every element -- file or directory -- in ClearCase has at least one version on "main"), but actually there is no trunk except the one branch you choose as trunk.

Branch =>集成流?开发流?

流不是分支。它是一个元数据,其中包含您需要工作的标签(基准)列表。也就是说,仅当您选择使用UCM时。否则,分支就是您可以在没有UCM( mkbranch myBranch )的情况下创建的任何分支。

流可以用作创建以以下名称命名的分支的模式它:您在UCM视图(在Stream之后自动配置的视图)中进行的任何签出都会创建一个以其流命名的分支。

Branch => Integration stream? development stream?
A stream is not a branch. It is a metadata with the list of labels (baselines) you need to work. At that is, only if you chooses to use UCM. Otherwise, a branch is any branch you can create without UCM (mkbranch myBranch).
A stream can serve as a pattern to create a branch named after it: any checkout you make within an UCM view (a view configured automatically after a Stream) will create a branch named after its stream.

标签=>标签?是基线吗?

首先,标签不是具有像UCM这样便宜的副本的目录。

它是应用于您需要引用它的任何版本的标签。

标签(非UCM)和基线(UCM)之间的区别在于,基线是应用于(UCM)组件(组的所有文件)的标签文件),而标签可以应用到您选择的任何元素上,例如仅是给定文件组的子集。

Tag => Label? Baseline?
First a tag is not a directory with a cheap copy like UCM.
It is a label applied on any version you need to be referenced by it.
The difference between a label (non-UCM) and a baseline (UCM) is that a Baseline is a label applied on all files of a (UCM) component (group of files), whereas a label can be applied on any element of your choice, like only a subset of a given group of file.

从repo作为工作副本=>从VOB作为快照视图签出?

差不多,但是快照视图的正确术语是更新。

对于动态视图,您甚至不需要更新(或svn签出),因为该视图是动态的:您可以通过网络立即看到正确的工作副本。

Checkout from repo as working copy => Checkout from VOB as snapshot view?
Almost, but the right term for snapshot view is "update".
For a dynamic view, you don't even need an update (or svn checkout), since the view is ... dynamic: you just see the right working copy through the network instantly. It is just another access mechanism.

是从工作副本提交到repo =>从快照视图签入到VOB吗?

不太正确,因为一次提交将涉及所有 个修改过的文件,而签入将逐个文件进行(即使ClearCase 7.1.1引入了 :请参见签入手册页)。

Commit from working copy into repo => Checkin from snapshot view into VOB?
Not quite, since a commit will concern all modified files, while a checkin will be file-by-file (even though ClearCase 7.1.1 has introduced the notion of "atomic checkin": see checkin man page).

Update =>重新设置基准?

Nope:表示在快照视图中进行更新(动态视图中无动态,因为它是动态的:在具有类似选择规则的另一个视图中所做的任何更改将立即在您的视图中显示)
Rebase是完成的UCM合并,它是从父流到子流的分支。最后,它只是一个合并。

Update => Rebase?
Nope: means update in snapshot view (an nothing in dynamic view since it is dynamic: any changes made in another view with similar selection rule will be visible instantly in your view)
Rebase is an UCM merge being done being a branch from a parent stream to a branch from a child stream. In the end, it is just a merge.

还原=> ??

并非无关紧要。 ..这是 主题合并

Revert => ??
Not trivial... It is a substractive merge.

??? =>交付

交付和重建只是分支源和分支目标之间的合并:

唯一的优势是您可以看到合并工作流事先定义流的层次结构(只不过是标签列表),知道之间的任何合并:

?? => Deliver
Deliver and Rebase are just merges between branch "source" and branch "destination":
The only advantage being you can "see" your merge workflow in advance be defineing a hierarchy of streams (which are nothing but a list of labels), knowing that any merge between:


  • 从子流到父流将是传递

  • 从父流到子流的分支将是变基

这篇关于SVN用户学习ClearCase的快速方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆