git - Accurev 工作原理的一句话解释是什么？

Question

我了解 git、Subversion、CVS 和无数其他源代码控制系统。

我已经开始使用 Accurev，它让我感到困惑。

我相信我需要形成一个将其与其他 SCM 相关联的心智模型。理想情况下相对于 git，因为我最了解 git。

我会将 git 解释为“提交的有向图，其中提交是差异、父(或父)哈希以及自身的哈希。”您可以轻松地从那里继续解释诸如 rebase 和 merge 真正是什么、快进与实际 merge 等概念。我发现在大约 15-20 分钟内教新用户复杂的 git 概念很容易。

我真的很想在那个层面上了解 Accurev。所以...

Accurev 工作原理的一次句子抽象是什么，可以解释它的行为方式？

我希望我的心智模型回答的一些问题示例:

当我“保留”一些文件然后“提升”它们时会发生什么？

如果我不宣传刚刚保存的相同文件怎么办？

为什么在发生非冲突(即重叠)更新时，历史有时会被错误归因？这尤其让人想起 Subversion 的失败模式，根据我听到的基本解释，我认为 Accurev 不应该存在。

为什么差异几乎从不包含我期望的内容？我相信发生的事情是，与基础的差异向我展示了与当前(移动)父流的差异，但我真正想要的只是查看自上次更新以来我所做的更改。

Answer 1

免责声明:我最了解的源代码控制系统是 SVN。因此，这影响了我对 repo、checkout 等术语的使用。此外，我每天都使用 Accurev，但我倾向于远离我认为我已经牢牢掌握的核心概念。

一句话(带星号): Accurev 是一个按时间排序的存储库，它保留每个流/工作区更改的文件的修订历史记录，并允许您开发不同版本的代码(在流中)，同时每个流都使用其父级和子级的核心代码透明更新* 流。

(*) 只有在子流将更改提升到父流中时，子流才会更新流。

Accurev 的主要好处是能够轻松维护不同版本的代码。如果您想掌握它，我不会寻找用您熟悉的语言重新定义的快速抽象或术语。当它们出现时，我会寻找例子和对术语的温和解释。不幸的是，我只知道我需要知道的，但我会试一试......

(我稍后会去工作区。此时不要担心它们。)

当你创建一个流的父流时，就像你做了一个 SVN 分支来创建子流，但(美妙的)区别在于每次更新父流或子流时都会为你处理 SVN merge (或当存在冲突并且您需要手动解决它时，您会收到警报)。

假设您从一个流 CompanyStream 开始。您的代码库由该流管理，并且它具有您对文件所做更改的历史记录。然后您决定在其下方创建两个子流，ChildStream1 和 ChildStream2。对 CompanyStream 中的文件所做的任何更改都将渗透到两个子流中，因此它们始终具有从 CompanyStream 继承的最新代码。 (修订更改的继承是 Accurev 中的一个主要概念。)同时，您正在针对 ChildStream1 中的一个供应商进行开发，并针对 ChildStream2 中的另一个供应商进行更改。您可以有选择地决定将 ChildStream1 和 2 中的哪些代码提升到 CompanyStream，但在 CompanyStream 中所做的任何更改都应该是您希望出现在两个子流中的内容。如果您将 ChildStream1 中的代码提升到 CompanyStream 中，那么一旦进行更新，这些更改将出现在 ChildStream2 中(因为它再次继承了 CompanyStream)

流可视化如下所示:

公司流 --
|-- ChildStream1
|-- ChildStream2

Accurev Overlap = 自您更新流后，父流中的文件已被修改。将父流可视化为在您上方(这就是它在客户端中的显示方式)，并且该流已水平推进，因此它与您所在的时间点重叠。

SVN 到 Accurev 概念的快速映射:
SVN 签到 - 推广
SVN Checkout - Anchor( anchor 定某物使其成为 WIP - 正在进行中)
SVN 更新 - 更新

Accurev 工作区

我还没有提到工作区。工作区代表硬盘驱动器上的代码。工作区类似于流，因为它可以有历史记录，并且可以跟踪您所做的更改。 (这就是 Keep 的作用——它将您在 Keep 操作期间指定的文件的快照存储在您的工作区历史记录中。您可以随时恢复到这些文件快照。因此，工作区也可以被视为您的自己的个人私有(private)流，这是对其中代码所做更改的记录。)

Streams 是抽象的概念，代表修订更改，以及发生的事情的历史。流和工作区从其父流继承代码。然而，与流不同，工作区不能有子流或子工作区。工作区就像树上的叶子；溪流就像 Twig 。

当我“保留”一些文件然后“提升”它们时会发生什么？

你提升到一个流。你保持到一个工作区。所有可以看到流的人都可以看到升级的更改。保留的更改仅对您(工作区的所有者)可见。

Kept 文件将在您的工作区中有快照(以防您想恢复它们)。提升的文件将在您提升它们的流中具有快照(可以这么说)。最大的区别在于，提升的更改将渗透到继承该流的任何流或工作区。

如果我不宣传刚刚保存的相同文件怎么办？

那么它们只会出现在您的工作区中。此外，我相信当您进行升级时，Accurev 会先保留(因此您在工作区和要升级到的流中都有文件更改的记录)。

为什么在发生非冲突(即重叠)更新时，历史有时会被错误归因？这尤其让人想起 Subversion 的失败模式，根据我听到的基本解释，我认为 Accurev 不应该存在。

能给我举个例子吗？我对 Accurev 文件版本控制的理解有点模糊。我相信版本属性将由提升最近更改(而不是保留)的工作区或流分配。有可能存在一些流继承关系导致文件的属性在您追踪它之前似乎不正确。

为什么差异几乎从不包含我期望的内容？我相信发生的事情是，与基础的差异向我展示了与当前(移动)父流的差异，但我真正想要的只是查看自上次更新以来我所做的更改。

然后对“Backed”做一个diff，而不是对Basis。

对我有用的简单配置是:我总是从一些公共(public)开发流中创建自己的个人私有(private)流。然后，当我做出想要 checkin (或能够恢复)的更改时，我会升级到我自己的流。我一直在我的工作区工作，如果我想将我的工作区与我之前所做的或我上面发生的事情(其他人所做的更改)进行比较，我会与 Backed 进行比较。

对不起，这么久。希望它有帮助...