我理解git，Subversion，CVS和无数其他源代码控制系统。
我已经开始使用Accurev了，这让我很困惑。
我认为我需要形成一个与其他SCM相关的心理模型。理想情况下相对于git，因为我理解git是最好的。
我会将git解释为“提交的有向图，其中提交是diff，父（或父）哈希，以及自身的哈希。”您可以轻松地从那里继续解释像rebase这样的概念以及合并的实际情况，快进与实际合并等等。我发现在大约15-20分钟内教新用户复杂的git概念很容易。
我真的很想了解那个级别的Accurev。所以......
Accurev如何工作的一次句抽象是什么使得解释它的行为成为可能？
我想让我的心理模型回答一些问题的例子：
答案 0 :(得分：25)
答案 1 :(得分：5)
由于其他几个人试图回答你的直接问题 - 戴夫的回答是最简洁和准确的 - 我会捅你的子弹：
当我“保留”某些文件然后“提升”它们时会发生什么？
保留文件将创建该文件的新版本，仍然是您工作区的私有版本。非常适合自动编码，创建转移点，只是简单的私人开发。您可以在将来的任何时间恢复到任何以前保存的文件版本，无论是您自己还是来自任何其他贡献者。当你对当前的版本感到满意（你已经编译，构建，测试，等等），你可以将它推广到你的父流中，从而将其他人暴露给你的版本，而不会有你在提交时破坏的风险在办理登机手续时。
如果我不推广与我刚才保存的文件相同怎么办？
再次，总工作空间自治。如果您是那种可以跟踪您正在做的事情的开发人员，那么您可以同时处理100个文件。你可以推广没有，全部，一个，一些 - 并不重要 - 你可以在时间轴上做到这一点。
为什么在发生非冲突（a.k.a.重叠）更新时，历史记录有时会被错误归因？特别是这让人想起Subversion的失败模式，从我听过的基本解释来看，我认为Accurev不应该存在。
我不确定我具体知道你在这里指的是什么。在AccuRev工作区中运行更新时，它将永远不会覆盖您正在进行的工作。如果您正在处理否则将继承的元素 - 意味着父层次结构中的内容已更改 - 它们将在工作区中列为（重叠）。同样，您可以选择何时执行合并，并仍然从上面更新其他更改，甚至继续处理冲突文件。合并发生在工作区中，而不是在Promote时间，让您可以选择在交付之前再次编译，构建和测试结果。
为什么差异几乎从不包含我期望的那些？我相信发生的事情是，基于差异的差异向我展示了当前（移动）父流的差异，但我真正想要的只是看到自我上次更新以来我所做的改变。
Diff against Basis将向您展示工作区中的版本与您上次从更新或工作区创建中继承的版本的比较。 Diff against Backed将显示您的版本与父流中当前的版本进行比较的方式。因此，如果有人在您仍在进行中的情况下提升了对该文件的更改，则Diff against Basis将仅与原始文件进行比较，而Diff for Backed则与父项中的新内容进行比较。顺便提一下，在历史中 - ＆gt;浏览版本视图，您可以将文件的任何两个版本相互区分开来。
希望这可以为您的具体问题提供一些视角。
答案 2 :(得分：3)
我会将git解释为“提交的有向图，其中提交是diff，父（或父）哈希，以及自身的哈希。”
git存储库是FWIW，它是历史树的森林，其中提交的叶子是（提交元数据加上）目录和文件的树。 没有差异，而不是Git，至少在概念方面。如果存储引擎碰巧做了解决，那就是另一个故事。
对于AccuRev，我看了their 2-minute introductory video（链接用于参考，而非广告），它看起来非常像平均时间安排的SCM历史树（分支）。带有水波图标的项目是分支头，黄色文件夹状的东西是工作副本。当主持人移动工作副本时，他似乎正在对他所有下属的工作副本进行改造（邪恶的！只考虑合并冲突！）。带有三个绿点（问题列表）的图标将是一个提交列表，然后在复制时将其挑选出来。
用一句话说：通过以前的cvs / svn / git经验你还不知道 - 跟我说的一样。
答案 3 :(得分：3)
Accurev为derived from ClearCase，在ClearCase UCM streams之后拍摄 （Accurev模型与UCM和well-received by former ClearCase users）
有一些相似之处Stream是配置，它是您需要工作（编译和/或测试，和/）的标签列表（对于只读组件）或文件（对于可写组件）或调试，...）。
这就是为什么Accurev以 Stream-Based Architecture for SCM 呈现。
如果每个开发人员（工作区流）有一个私有流，您可以从中提升到更常见的流。每个促销都会更新父流的配置（这也是您需要工作的列表）。
答案 4 :(得分：1)
我会根据你的Q风格给你技术（非商业）单句：
AccuRev采用面向对象的方法来建模s / w配置。就这么简单而且太棒了！特别是如果您正在建模工作流程或更好，建立持续交付（另一个主题）。但我已经看到了，很多人都不赞成这种强大的技术和数据模型方法，因为它们无法超越传统的“分支”，无论是svn，svn，p4，cc，还是无限。最好的比喻是将一系列AccuRev流与配置规范中的规则进行明确比较...（注意：这只是一个类比）但更强大，因为流是保持基于时间的配置和历史的一流实体。
理解AccuRev的技巧是，虽然任何给定的“流” - 表示完整配置（即你可以检查出来），但是通过聚合任何本地文件/目录更改动态确定该流的实际内容。从父级，在树上的更改到收集其余文件的最顶层。因此，只要你看到一个“树”的流，它们就不是分支......而是一系列基于继承的配置，其中顶部流类似于“超类”，所有[宏]子节点都是[子]子类。从开发，集成，QA等开始，新的文件/目录更改将在树中提升。
HTH _ dave