ClearCase 与 Git 版本控制

ClearCase vs. Git version control

提问by Anant

We are using a multisiteClearCaserepository, and often we require to merge and build our system. This merge and replication takes almost three days to be available across sites. Hence to be more efficient, we are planning to move to Gitversion control. Could you please advise of the potential drawback that we can encounter if we move to the Git from ClearCase?

我们正在使用多站点ClearCase存储库，并且经常需要合并和构建我们的系统。这种合并和复制几乎需要三天时间才能跨站点使用。因此，为了更高效，我们计划转向Git版本控制。如果我们从 ClearCase 迁移到 Git，您能否告知我们可能遇到的潜在缺陷？

回答by eddyp

@zzz777: Your question was asked in such a ClearCase centric view that it failed to be comprehensible to people who never used ClearCase before. In fact, Git is light years aheadof ClearCase, and it is the commercial SCMs that need to catch up with OSS systems.

@ zzz777：您的问题是以 ClearCase 为中心的观点提出的，以至于以前从未使用过 ClearCase 的人无法理解。事实上，Git领先于 ClearCase光年，而需要赶上 OSS 系统的是商业 SCM。

I have experience with both ClearCase and Git, and I can tell you that the Find merges (mis)feature of ClearCase is a result of its (fundamentally broken) design based on versioning files, but in Git you don't need such a primitive tool to merge the shared branch to your private branch. ClearCase is file-oriented, and checkin-s are file based, and that's why you need the Find (files) to merge utility, but Git is commit based, and that is the right model, since when you fix an issue or implement a feature, the entire changeset or none of it are the only options that make sense.

我有使用 ClearCase 和 Git 的经验，我可以告诉你，ClearCase 的 Find 合并（错误）功能是其基于版本控制文件的（根本上被破坏的）设计的结果，但在 Git 中你不需要这样的原语工具将共享分支合并到您的私有分支。ClearCase 是面向文件的，而 checkin-s 是基于文件的，这就是为什么您需要 Find (files) 来合并实用程序，但 Git 是基于提交的，这是正确的模型，因为当您修复问题或实施功能，整个变更集或没有一个是唯一有意义的选项。

Git has a very powerful merge feature, and it does the right thing. There are two ways to do what you are asking (updating your private branch to be the shared branch + your changes).

Git 有一个非常强大的合并功能，它做正确的事。有两种方法可以完成您的要求（将您的私有分支更新为共享分支+您的更改）。

The most obvious is to do a merge, so while on your private branch you just do:

最明显的是进行合并，因此在您的私有分支上，您只需执行以下操作：

git merge sharedbranch

then, if there are conflicts (really a lot more rare than in ClearCase), you resolve them and

然后，如果有冲突（真的比 ClearCase 少得多），你解决它们并

git commit

And that's it. As a bonus, because Git has all history locally, you don't have to waste countless hours, if you have lots of files, like you do in ClearCase, the merge is blazingly fast, by the time ClearCase in a dynamic view does a merge of 10 files, Git will probably finish merging 100, easily.

就是这样。作为奖励，因为 Git 在本地拥有所有历史记录，所以您不必浪费无数个小时，如果您有很多文件，就像在 ClearCase 中所做的那样，合并速度非常快，当动态视图中的 ClearCase 执行合并 10 个文件，Git 可能会轻松完成合并 100 个文件。

Using git mergemeans that you preserve history and if your history looked like this before the merge:

使用git merge意味着你保留历史，如果你的历史在合并前看起来像这样：

o---1---2---3 (sharedbranch)
 \
  a---b---c (privatebranch)

after the merge it will look like this:

合并后，它将如下所示：

o---1---2---3 (sharedbranch)
 \           \
  a---b---c---m (privatebranch)

This preserves the history of your changes and can allow others to review your work.

这会保留您更改的历史记录，并允许其他人查看您的工作。

And remember, these are NOT file revision histories. These if the tree history, which is the only history that makes sense to store, even if branches differ only by one or two files. The state you want to preserve is the tree, not one file.

请记住，这些不是文件修订历史。这些是树历史，这是唯一可以存储的历史，即使分支仅相差一两个文件。您要保留的状态是树，而不是一个文件。

The second option is to use rebase, which means that you make it like it seems al your changes have been made starting from the latest code on the shared branch.

第二个选项是使用 rebase，这意味着你让它看起来好像你的更改是从共享分支上的最新代码开始的。

The command you use (again, while on the private branch):

您使用的命令（同样，在私有分支上）：

git rebase sharedbranch

The history tree will change from:

历史树将从：

o---1---2---3 (sharedbranch)
 \
  a---b---c (privatebranch)

to

到

o---1---2---3 (sharedbranch)
             \
              a'--b'--c' (privatebranch)

So if you give Git some time to understand it, and use it a little, you'll see how much better is the Git model and how broken the ClearCase model is.

因此，如果您给 Git 一些时间来理解它，并稍微使用它，您就会看到 Git 模型有多好，以及 ClearCase 模型有多糟糕。

BTW, the evil twin problem in ClearCase simply does not exist in Git because Git does not track directories (trust me, you do notneed that).

顺便说一句，在ClearCase中邪恶的孪生问题根本不存在的Git因为Git不会追踪目录（相信我，你就不会需要一个）。

Also, if you ever had a configuration specification, which is a little more complicated with several branches and you migrated files from one branch to the other, you probably know how important the order of the rules in the configuration specification is, and how frustrating is to see old versions of files because the configuration specification is "wrong". That happens in ClearCase due to its base design, and, needless to say, that kind of crap can't happen in Git.

此外，如果您曾经有一个配置规范，它有几个分支会稍微复杂一些，并且您将文件从一个分支迁移到另一个分支，那么您可能知道配置规范中规则的顺序是多么重要，并且是多么令人沮丧查看旧版本的文件，因为配置规范是“错误的”。由于其基本设计，这在 ClearCase 中发生，不用说，这种废话在 Git 中不会发生。

So, to conclude, Git does not have a primitive tool such as "find merge", because it does not need it. It has a superior model and superior merge model which actually works. It is lightning fast compared to ClearCase (CCRC static view or dynamic view, you name it).

所以，总而言之，Git 没有像“find merge”这样的原始工具，因为它不需要它。它有一个实际工作的高级模型和高级合并模型。与 ClearCase（CCRC 静态视图或动态视图，随便你说）相比，它快如闪电。

The only place ClearCase could have an edge is the instantaneous update of the dynamic view, but that is also mitigated by the fact that you can type faster git checkout branchthan you can update the configuration specification.

ClearCase 唯一可能具有优势的地方是动态视图的即时更新，但由于您可以键入比更新配置规范更快的git checkout 分支，这一点也得到了缓解。

回答by PAntoine

Problems that I have had in a professional mixed ability office:

我在专业混合能力办公室遇到的问题：

1. Mutable History. You can do some really silly (and powerful) things with Git. This can cause source loss.
2. Auto Merging. This is the best feature of Git. But, we had to shut development down for a week to find the source code that went missing. MSVS has a happy issue with randomly changing line endings and if you don't pull from the repository regularly it gets confused, and changes get lost.
3. Push/Pull order. ClearCase handles the date ordering and history for you, but Git ignores it.
4. Staging. ClearCase (at least UCM) handles branch promotion and other things for you. Git does not. You will have to manage this carefully.
5. $ID$ Does not exist for Git. Version tracking from actual releases and problem finding from knowing what the version of the source file is will have to be handled manually. (I am not sure what your release process is.)

1. 可变历史。你可以用 Git 做一些非常愚蠢（而且强大）的事情。这会导致源丢失。
2. 自动合并。这是 Git 最好的特性。但是，我们不得不关闭开发一周才能找到丢失的源代码。MSVS 有一个随机改变行尾的令人愉快的问题，如果你不定期从存储库中提取，它会变得混乱，并且更改会丢失。
3. 推/拉订单。ClearCase 为您处理日期排序和历史记录，但 Git 会忽略它。
4. 分期。ClearCase（至少是 UCM）为您处理分支促销和其他事情。Git没有。你必须小心地管理这个。
5. $ID$ 对于 Git 不存在。必须手动处理来自实际版本的版本跟踪和通过了解源文件的版本来发现问题。（我不确定您的发布过程是什么。）

For you final code repository, I might suggest a release repository, either another source control system or a separate Git repository, that is managed and only accepts pulls.

对于您的最终代码存储库，我可能会建议一个发布存储库，另一个源代码控制系统或一个单独的 Git 存储库，它是受管理的并且只接受拉取。

I am currently using Git for my solo project, and it is fine. But, in a mixed-ability house with a variety of editors I would be careful. You can really blow you foot off without knowing with Git.

我目前在我的个人项目中使用 Git，这很好。但是，在一个有各种编辑的混合能力的房子里，我会小心。你真的可以在不知道 Git 的情况下大吃一惊。

I have not used either, Mercurialor Bazaar. It might be worth looking at these as some of the problems go away, and they have features to mitigate some of the above problems.

我没有使用过Mercurial或Bazaar。随着一些问题的消失，可能值得研究这些，并且它们具有减轻上述一些问题的功能。

回答by VonC

As I mentioned in "What are the basic ClearCase concepts every developer should know?", ClearCase might have some "decentralized" features with its multi-site repos, but it still a CVCS at its core:

正如我在“每个开发人员应该知道的基本 ClearCase 概念是什么？”中提到的那样，ClearCase 可能具有一些带有多站点存储库的“分散”功能，但它的核心仍然是 CVCS：

• it has a strong link with system user-id (which isn't relevant in a DVCS, where there is no unique user referential).

• it has a unique repo for managing label and branch names (admin vob), while you can define a 'test' branch in 15 different Git repos without problem (except you need to know what repo1/teststands for, relative to repos2/test).

• it also centralize a merge workflow definition through the (UCM) Stream hierarchy (you can visualize where you are supposed to merge a work from one Stream to another).

• it proposes through UCM a definition of subset of codes (component), with dependency management. Git only has submodules, without override/overridden detection mechanism.

• it manages any kind of files, even large binaries, while a DVCS (any kind of DVCS) is better off managing only source code.

• 它与系统用户 ID 有很强的联系（这在没有唯一用户引用的 DVCS 中不相关）。

• 它有一个用于管理标签和分支名称（admin vob）的独特存储库，而您可以毫无问题地在 15 个不同的 Git 存储库中定义“测试”分支（除非您需要知道repo1/test相对于 的含义repos2/test）。

• 它还通过 (UCM) Stream 层次结构集中合并工作流定义（您可以将工作从一个 Stream 合并到另一个 Stream 的位置可视化）。

• 它通过 UCM 提出了代码子集（组件）的定义，具有依赖性管理。Git 只有子模块，没有覆盖/覆盖检测机制。

• 它管理任何类型的文件，甚至是大型二进制文件，而 DVCS（任何类型的 DVCS）最好只管理源代码。

The bottom-line (in our migration from ClearCase to Git) is that it involves quite a few refactoring/reorganization of the source code in order to have manageable Git repositories.

底线（在我们从 ClearCase 迁移到 Git 的过程中）是为了拥有可管理的 Git 存储库，它涉及大量的源代码重构/重组。

回答by kmatheny

I've worked with both Git and ClearCase and once you learnhow to use Git and thenmake the switch, you'll never look back. Make sure that you have the time to train your developers -- this should be your top priority. Git is an entirely different approach to SCM than ClearCase.

我曾经使用过 Git 和 ClearCase，一旦你学会了如何使用 Git然后进行转换，你将永远不会回头。确保您有时间培训您的开发人员——这应该是您的首要任务。Git 是一种与 ClearCase 完全不同的 SCM 方法。

Some things to consider (possible downsides):

需要考虑的一些事情（可能的缺点）：

1. You will need a truerepository master, not just someone to watch over the source, but someone who understands how the SCM actually works (not just what a GUI displays to them) and can handle your branching model (see #2)
2. Adopt/develop a robust branch model. A great example, and one I've used is A successful Git branching model
3. You're going to have to invest a great deal of time helping your developers relearn everything they thought they knew about using/interacting with an SCM.

1. 您将需要一个真正的存储库管理员，不仅是监视源代码的人，而且是了解 SCM 实际工作方式（不仅仅是 GUI 向他们显示的内容）并且可以处理您的分支模型的人（参见 #2）
2. 采用/开发强大的分支模型。一个很好的例子，我用过的一个是一个成功的 Git 分支模型
3. 您将不得不投入大量时间来帮助您的开发人员重新学习他们认为他们知道的有关使用/与 SCM 交互的所有内容。

If you can overcome the three above, then there's very little downside (#3 being the toughest). As for @PAntoine, most of those issues are related to training -- #1 would have to require a truly poor decision to lose source code. git reflogwill provide you access to every commit to the repository. The only way to destroy source would be through git reflog expire --expire=whatever refs/heads/master, git fsck --unreachable, git prune, and git gc, which should only be handled by the repository master -- and then there's the universal issue of a developer not committing their source (D'oh!)

如果你能克服以上三个，那么缺点就很小（#3 是最难的）。至于@PAntoine，大部分问题都与培训有关——#1 必须做出真正糟糕的决定才能丢失源代码。git reflog将为您提供对存储库的每次提交的访问权限。销毁源代码的唯一方法是通过git reflog expire --expire=whatever refs/heads/master, git fsck --unreachable, git prune, 和git gc，这应该只由存储库管理员处理 - 然后是开发人员不提交他们的源代码的普遍问题（D'oh！）

回答by Legna

Do you need a tool to help you with your software configuration management (SCM) or your version control [system] (VCS)?

您是否需要一个工具来帮助您进行软件配置管理 (SCM) 或版本控制 [系统] (VCS)？

That's what the ClearCase vs Git discussion boils down to.

这就是 ClearCase 与 Git 的讨论归结起来的内容。

So to speak you are comparing apples to oranges.

可以这么说，您正在将苹果与橙子进行比较。

Thinking of ClearCase as just another VCS is a narrow view of what ClearCase is; stick with ClearCase if your goal is shipping the right product out of your shop.

将 ClearCase 视为另一个 VCS 是对 ClearCase 的狭隘看法；如果您的目标是将正确的产品运出您的商店，请坚持使用 ClearCase。

On the other hand Git is probably the best VCS on the market at this moment, (though it does not offer any SCM support) so you switch to it if your concern is branching and merging .... (a side note the merging conflicts are the result of a poorly set base line and improperly configured views) ... VOB replication sucks - I give you that.

另一方面，Git 可能是目前市场上最好的 VCS，（尽管它不提供任何 SCM 支持）所以如果你关心的是分支和合并，你可以切换到它......（注意合并冲突是基线设置不当和视图配置不当的结果）...... VOB 复制很糟糕 - 我给你。

The drawback of your planned move is that you will throw away your SCM tooling support. And you will have to face a myriad of other tools and lots of manual work to achieve what you had out of the box with ClearCase.

您计划搬迁的缺点是您将丢弃 SCM 工具支持。您将不得不面对无数其他工具和大量手动工作，以实现您使用 ClearCase 开箱即用的功能。

Anyway a good VCS is the backbone of any SCM, so your move to Git might payoff in the long run.

无论如何，一个好的 VCS 是任何 SCM 的支柱，所以从长远来看，你转向 Git 可能会得到回报。