30

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

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

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

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

我真的很想了解那个级别的 Accurev。所以...

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

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

  • 当我“保留”一些文件然后“提升”它们时会发生什么？
  • 如果我不推广刚刚保存的相同文件怎么办？
  • 为什么在发生非冲突（又名重叠）更新时，历史有时会被错误归因？这尤其让人想起 Subversion 的故障模式，根据我听到的基本解释，我认为 Accurev 不应该存在这种模式。
  • 为什么差异几乎从不包含我期望的内容？我相信发生的事情是，与基础的差异向我展示了与当前（移动）父流的差异，但我真正想要的只是看到自上次更新以来我所做的更改。
4

5 回答 5

27

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

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

(*)仅当子流将更改提升到父流时，子流才会更新流。

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

（我稍后会进入工作区。此时不要担心它们。）

当您创建一个以另一个为父的流时，就像您创建了一个 SVN 分支来创建子流一样，但是（奇妙的）区别在于，每次更新父流或子流（或当存在冲突并且您需要手动解决冲突时，您会收到警报）。

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

流可视化如下所示：

CompanyStream --
                            |-- ChildStream1
                            |-- ChildStream2

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

SVN 到 Accurev 概念的快速映射：
SVN Checkin - 促进
SVN Checkout - 锚（锚定某物使其成为 WIP - 正在进行中）
SVN 更新 - 更新

Accurev 工作区

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

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

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

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

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

  • 如果我不推广刚刚保存的相同文件怎么办？

然后它们只会在您的工作区中。另外，我相信当您进行促销时，Accurev 会首先保留（因此您在工作区和要促销的流中都有文件更改的记录）。

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

能给我举个例子吗？我对 Accurev 的文件版本控制的把握有点模糊。我相信版本属性将由提升最近更改（而不是保留）的工作区或流分配。有可能存在一些流继承关系，导致文件具有看起来不正确的属性，直到您对其进行跟踪。

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

然后对“Backed”进行比较，而不是对 Basis。

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

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

于 2011-01-18T15:28:04.183 回答
7

由于其他几个人试图回答你的直接问题——戴夫的回答是最简洁和准确的——我会猛烈抨击你的子弹：

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

    保留文件将创建该文件的新版本，仍然是您工作区的私有版本。非常适合自主编码，创建转移点，只是普通的私人开发。您可以在未来的任何时间恢复到任何以前保存的文件版本，无论是来自您自己还是来自任何其他贡献者。当您对当前的版本感到满意时（您已经编译、构建、测试等等），您可以将其提升到您的父流中，从而将其他人暴露给您的版本，而不会像您在提交时那样破坏事情的风险在入住时间。

  • 如果我不推广刚刚保存的相同文件怎么办？

    再次，完全的工作空间自主权。如果您是那种可以跟踪您正在做什么的开发人员，您可以一次处理 100 个文件。您可以推广无、全部、一个、一些 - 并不重要 - 您可以在时间轴上执行此操作。

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

    不知道我具体知道你在这里指的是什么。当您在 AccuRev 工作区中运行更新时，它永远不会覆盖您正在进行的工作。如果您正在处理原本会被继承的元素 - 意味着您的父层次结构中的内容已更改 - 它们将在您的工作区中列为（重叠）。同样，您可以选择何时执行合并，仍然可以从上面更新其他更改，甚至继续处理有冲突的文件。合并发生在工作区中，而不是在升级时，让您可以选择在其他地方交付之前再次编译、构建、测试结果。

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

    A Diff against Basis 将显示您的工作区中的版本与您上次从更新或工作区创建继承的版本相比如何。A Diff against Backed 将向您展示您的版本与当前父流中的版本相比如何。因此，如果有人在您仍在进行更改的情况下对该文件进行了升级，则 Diff against Basis 只会与您的原始内容进行比较，而 Diff against Backed 将与父项中的新内容进行比较。顺便说一句，在 History -> Browse Versions 视图中，您可以将文件的任何两个版本相互比较。

希望这可以为您的具体问题提供一些观点。

于 2011-01-07T21:01:33.460 回答
3

Accurev派生自 ClearCase并采用ClearCase UCM 流。
（Accurev 模型与 UCM 有一些相似之处，并且深受前 ClearCase 用户的欢迎）

Stream 是一种配置，即您需要工作（编译、和/或测试、和/或调试...）的标签（用于只读组件）或文件（用于可写组件）的列表。

这就是 Accurev 被呈现为 SCM 的基于流的架构的原因。

如果每个开发人员有一个私有流（工作区流），您可以从中升级到更常见的流。每个促销都会更新父流的配置（这也是您需要工作的列表）。

于 2011-01-07T06:43:48.010 回答
3

我会将 git 解释为“提交的有向图，其中提交是差异、父（或父）哈希和自身的哈希”。

git 存储库 FWIW 是历史树的森林，其中提交叶是（提交元数据加上）目录和文件树。没有 diffs，在 Git 中没有，至少在概念方面是这样。如果存储引擎恰好进行了分类，那就是另一回事了。

至于 AccuRev，我观看了他们 2 分钟的介绍视频（链接仅供参考，而非广告），它看起来很像您的平均时间安排的 SCM 历史树（分支）。带有水波图标的项目是分支头，黄色文件夹状的东西是工作副本。当演示者移动工作副本时，他似乎正在对其下属的所有工作副本进行变基（邪恶！想想合并冲突！）。带有三个绿点的图标（问题列表）将是一个提交列表，然后在您复制它时会被挑选出来。

一句话：通过之前的 cvs/svn/git 经验，没有什么是你不知道的——我想说的是继续前进。

于 2011-01-07T00:18:16.473 回答
1

我会根据你的 Q 风格给你技术（非商业）单句：

AccuRev 采用面向对象的方法对软件配置进行建模。就是这么简单，太棒了！特别是如果您正在对工作流程进行建模或更好地设置持续交付（另一个主题）。但我已经看到了，很多人不屑一顾这种强大的技术和数据模型方法，因为他们无法超越传统的“分支”，如 cvs、svn、p4、cc、无限。最好的类比是将一系列 AccuRev 流与 clearcase 中的配置规范中的规则进行比较......（注意：这只是一个类比）但更强大，因为流是维护基于时间的配置和历史的一流实体。

理解 AccuRev 的诀窍是，虽然任何给定的“流” - 代表 - 一个完整配置（即您可以检查它），但该流的实际内容是通过聚合任何本地文件/目录更改动态确定的，来自父级，在树的最顶部收集其余文件。因此，无论何时您看到流的“树”，它们都不是分支……而是一系列基于继承的配置，其中顶级流就像“超类”，所有 [grand] 子类都是 [sub] 子类。新的文件/目录更改在开发、集成、QA 等过程中被提升到树上。

HTH_戴夫

于 2011-01-07T05:36:18.413 回答