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

What is a one-sentence explanation of how Accurev works?

提问by Otto

I understand git, Subversion, CVS and a myriad of other source control systems.

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

I've begun using Accurev and it confounds me.

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

I believe I need to form a mental model that relates it to other SCM's. Ideally relative to git because I understand git the best.

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

I would explain git as "a directed graph of commits where a commit is a diff, a parent (or parents) hash, and a hash of itself." You can easily move on from there to explain concepts like rebase and what merges really are, fast-forward vs. actual merges and so on. I've found it easy to teach new users complex git concepts in about 15-20 minutes.

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

I would really like to understand Accurev at that level. So...

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

What is the once sentence abstraction of how Accurev works that makes it possible to explain how it behaves?

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

Some examples of questions I would like my mental model to answer:

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

• What happens when I "keep" some files and then "promote" them?
• What if I don't promote the same files as I've just kept?
• Why does history sometimes get mis-attributed when non-conflicting (a.k.a. overlapping) updates happen? This, in particular, is reminiscent of a failure mode of Subversion that, from the basic explanations I've heard, I don't believe should exist with Accurev.
• Why do diffs almost never contain what I expect them to? I believe what's happen is that diff against basis is showing me the diff against the current (moving) parent stream but what I really want is only to see changes I've made since I've last updated.

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

采纳答案by compilererror

Disclaimer:The source control system I understand best is SVN. So that colors my usage of terms such as repo, checkout, etc. Also, I use Accurev on a daily basis, but I tend not to venture far from the core concepts that I feel I have a firm grasp of.

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

One sentence (with an asterisk):Accurev is a time-ordered repository that keeps a revision history of files changed for each stream/workspace, and allows you to develop different versions of the code (in streams) while each stream is transparently updated with the core code from its parent and child* streams.

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

(*)A stream is updated by a child stream only once a child stream promotes changes into the parent stream.

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

The main benefit of Accurev is the ability to maintain different versions of code easily. If you want to grasp it, I wouldn't look for quick abstractions or terms redefined in language you're familiar with. I'd look for examples and a gentle explanation of terms as they arise. Unfortunately, I only know what I need to know, but I'll give it a shot...

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

(I'll get to workspaces later. Don't worry about them at this point.)

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

When you create one stream parented off of another, it's like you did an SVN branch to create the child stream, but the (wonderful) difference is that SVN merges are taken care of for you each time you update the parent or child stream (or you are alerted when a conflict exists and you need to resolve it manually).

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

Let's say you start off with a stream, CompanyStream. Your codebase is managed by that stream, and it has a history of changes you've made to files. You then decide to create two child streams below that, ChildStream1, ChildStream2. Any changes made to files in CompanyStream will trickle down to both child streams, so they always have the latest code that they inherited from CompanyStream. (Inheritance of revision changes is a staple concept in Accurev.) Meanwhile, you're doing development specific to one vendor in ChildStream1, and changes specific to another vendor in ChildStream2. You can selectively decide which code from ChildStream1 and 2 get promoted to CompanyStream, but any changes made in CompanyStream should be things that you want to appear in both child streams. If you promote code from ChildStream1 into CompanyStream, then those changes will appear in ChildStream2 once it does an update (because again, it inherits CompanyStream)

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

The stream visualization would look like this:

流可视化如下所示：

CompanyStream --
                            |-- ChildStream1
                            |-- ChildStream2

CompanyStream --
                            |-- ChildStream1
                            |-- ChildStream2

Accurev Overlap = A file in a parent stream has been modified since you've Updated your stream. Visualize the parent stream as being above you (that's how it'll be displayed in the client), and that stream has progressed horizontally so that it overlaps the point in time that you're at.

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

Quick mapping of SVN to Accurev concepts:
SVN Checkin - Promote
SVN Checkout - Anchor (Anchoring something makes it a WIP - Work In Progress)
SVN Update - Update

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

Accurev Workspaces

Accurev 工作区

I haven't mentioned workspaces yet. A workspace represents the code on your hard drive. A workspace is similar to a stream in that it can have a history, and it can keep track of changes you have made. (This is what a Keep does -- it stores a snapshot of the files you specify during that Keep operation in your workspace's history. You can revert to those file snapshots at any time. As a result, a workspace can also be viewed as your own personal, private stream, which is a record of changes made to the code within.)

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

Streams are abstract concepts that represent revision changes, and a history of what has happened. Streams and workspaces inherit the code from their parent streams. Unlike streams, however, workspaces cannot have child streams or child workspaces. Workspaces are like leaves on a tree; streams are like branches.

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

• What happens when I "keep" some files and then "promote" them?

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

You promote to a stream. You Keep to a workspace. Promoted changes are visible to all who can see the stream. Kept changes are visible only to you, the owner of the workspace.

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

The Kept files will have snapshots in your workspace (in case you ever want to revert to them). The promoted files will have snapshots (so to speak) in the stream you promoted them to. The big difference is that the promoted changes will trickle down to any streams or workspaces that inherit that stream.

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

• What if I don't promote the same files as I've just kept?

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

Then they will only be in your workspace. Also, I believe that when you do a promote, Accurev does a keep first (so you have a record of the file change in both your workspace and the stream to which you're promoting).

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

• Why does history sometimes get mis-attributed when non-conflicting (a.k.a. overlapping) updates happen? This, in particular, is reminiscent of a failure mode of Subversion that, from the basic explanations I've heard, I don't believe should exist with Accurev.

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

Can you give an example? My grasp of Accurev's file versioning is a little fuzzy. I believe that the version attribute will be assigned by the workspace or stream from which the most recent change was promoted (not Kept). It's possible that there are some stream inheritance relationships that cause a file to have attributes that don't seem correct until you trace it out.

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

• Why do diffs almost never contain what I expect them to? I believe what's happen is that diff against basis is showing me the diff against the current (moving) parent stream but what I really want is only to see changes I've made since I've last updated.

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

Then do a diff against "Backed," not against Basis.

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

The simple configuration that works for me is: I always create my own personal, private stream off of some public development stream. Then when I make changes I want to checkin (or be able to revert to), I promote to my own stream. I keep working in my workspace, and if I want to diff my workspace against what I've done previously or what's going on above me (changes that other people have made), I do a diff against Backed.

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

Sorry this is so long. Hopefully it helps...

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

回答by jtalbott

Since several others have attempted to answer your direct question - with Dave's answer being the most concise and accurate - I'll take a stab at your bullets:

由于其他几个人试图回答您的直接问题 - 戴夫的回答是最简洁和准确的 - 我将刺伤您的子弹：

• What happens when I "keep" some files and then "promote" them?

  A Keep of a file will create a new version of that file, still private to your workspace. Excellent for autonomous coding, creation of diversion points, just plain private development. You can at any time in the future revert to any previous kept version of a file, either from yourself or from any other contributor. When you are comfortable with the version you have current (you've compiled, built, tested, whatever), you can Promote it into your parent stream, thus exposing others to your version without the risk of breaking things like you can when you commit at check-in time.

• What if I don't promote the same files as I've just kept?

  Again, total workspace autonomy. You can work on 100 files at once if you're the kind of developer who can keep track of what you're doing. You can Promote none, all, one, some - doesn't really matter - and you can do this on your timeline.

• Why does history sometimes get mis-attributed when non-conflicting (a.k.a. overlapping) updates happen? This, in particular, is reminiscent of a failure mode of Subversion that, from the basic explanations I've heard, I don't believe should exist with Accurev.

  Not sure I know specifically what you're referring to here. When you run an Update in an AccuRev workspace, it will never overwrite your work-in-progress. If you're working on elements that would otherwise be inherited - meaning the content in your parent hierarchy has changed - they will be listed as (overlap) in your workspace. Again, you can choose when to perform the merge, and still Update other changes from above, and even continue working on the file in conflict. The merge happens in the workspace, as opposed to at Promote time, giving you the option to once again compile, build, test the result prior to delivering elsewhere.

• Why do diffs almost never contain what I expect them to? I believe what's happen is that diff against basis is showing me the diff against the current (moving) parent stream but what I really want is only to see changes I've made since I've last updated.

  A Diff against Basis will show you how the version in your workspace compares to the version that you last inherited from an update or workspace creation. A Diff against Backed will show you how your version compares to what is currently in the parent stream. So if someone has promoted changes to that file while you still have yours in progress, Diff against Basis will only compare against your original while Diff against Backed compares against the new content in the parent. Incidentally, in the History -> Browse Versions view you can diff any two versions of a file against each other.

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

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

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

  再次，完全的工作空间自治。如果您是那种可以跟踪您所做工作的开发人员，您可以一次处理 100 个文件。你可以推广一个，所有，一个，一些 - 并不重要 - 你可以在你的时间表上做到这一点。

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

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

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

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

Hopefully this provides a bit of perspective about your specific questions.

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

回答by VonC

Accurev is derived from ClearCaseand takes after ClearCase UCM streams.
(The Accurev model has some similarities with UCM, and well-received by former ClearCase users)

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

A Stream is a configuration, that is the list of labels (for read-only components) or files (for writable components) you need to work (compile, and/or test, and/or debug, ...).

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

That is why Accurev is presented as a Stream-Based Architecture for SCM.

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

If has one private stream per developer (the workspace stream) from which you can promote to more common streams. Each promotion update the configuration (which again is just the list of what you need to work) of the parent stream.

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

回答by user562374

I would explain git as "a directed graph of commits where a commit is a diff, a parent (or parents) hash, and a hash of itself."

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

A git repository is, FWIW, a forest of history trees, of which the commit leaves are (commit metadata plus) trees of directories and files. No diffs, not in Git, at least when it comes to the concept. If the storage engine happens to do deltification, that is another story.

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

As for AccuRev, I watched their 2-minute introductory video(link intended for reference, not advertisement), and it looks pretty much like your average time-arranged SCM history tree (branches). The items with the watery-wave icon are branch heads, and the yellow folder-like thing is a working copy. When the presenter moves the working copies, he seems to be doing a rebase of all his subordinate's working copies (evil that! just think about the merge conflicts!). The icon with three green dots (the issue list) would be a commit list then that is cherry-picked when you copy it.

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

In one sentence: nothing you don't know already through prior experience to cvs/svn/git?— move along I'd say.

一句话：通过之前的 cvs/svn/git 经验，没有什么你不知道的？ - 我会说。

回答by user129236

I'll give you the technical (non-biz) single sentence based on the style of your Q:

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

AccuRev takes an object oriented approach to modeling s/w configurations. It's that simple and it's awesome! Especially if you're modeling a workflow or better yet, setting up continuous delivery (another topic). But I've seen so, so many people dismiss this powerful technology and data model approach because they cannot look beyond traditional 'branches' ala cvs, svn, p4, cc, ad infinitum. The best analogy would be to compare a series of AccuRev streams to rules in a config spec in clearcase... (note: it's just an analogy) but much more powerful as streams are first class entities that maintain time-based configuration and history.

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

The trick to understanding AccuRev is that while any given "stream" -represents- a full configuration (i.e. you can check it out), the actual contents of that stream are determined dynamically by aggregating any local file/dir changes, any changes from the parent, on up the tree to the very top where the rest of the files are gathered. So anytime you see a 'tree' of streams, they are NOT branches... rather a series of inheritance based configurations where the top stream is like the 'superclass' and all [grand]children are [sub]subclasses. New file/dir changes are promoted up the tree as they go from development, integration, QA, etc.

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

HTH _ dave

HTH_戴夫