我理解git,Subversion,CVS和无数其他源代码控制系统.
我已经开始使用Accurev而且让我很困惑.
我相信我需要形成一个与其他SCM相关的心理模型.理想情况下相对于git,因为我理解git是最好的.
我会将git解释为"提交的有向图,其中提交是diff,父(或父)哈希,以及自身的哈希." 您可以轻松地从那里继续解释像rebase这样的概念以及合并的实际情况,快进与实际合并等等.我发现在大约15-20分钟内教新用户复杂的git概念很容易.
我真的很想了解那个级别的Accurev.所以...
什么是Accurev如何工作的一次句抽象,可以解释它的行为？
我希望我的心理模型回答的一些问题示例:
小智 25
免责声明:我最了解的源控制系统是SVN.因此,我使用了repo,checkout等术语.此外,我每天都使用Accurev,但我倾向于远离我认为我已经牢牢掌握的核心概念.
一句话(带星号): Accurev是一个按时间排序的存储库,它保存为每个流/工作空间更改的文件的修订历史记录,并允许您开发不同版本的代码(在流中),同时每个流都透明地更新来自其父级和子级*流的核心代码.
(*)仅当子流将更改提升到父流时,才会通过子流更新流.
Accurev的主要优点是能够轻松维护不同版本的代码.如果你想掌握它,我不会寻找快速抽象或用你熟悉的语言重新定义的术语.我会寻找实例和对术语的温和解释.不幸的是,我只知道我需要知道什么,但我会试一试......
(我稍后会进入工作区.此时不要担心它们.)
当你创建一个从另一个流为父级的流时,就像你创建了一个SVN分支来创建子流,但(精彩)区别在于每次更新父流或子流时都会为你处理SVN合并(或者)当存在冲突并且您需要手动解决时,会收到警报).
假设您从一个StreamStream流开始.您的代码库由该流管理,并且它具有您对文件所做的更改的历史记录.然后,您决定在ChildStream1,ChildStream2之下创建两个子流.对CompanyStream中的文件所做的任何更改都会向下传递到两个子流,因此它们始终具有从CompanyStream继承的最新代码.(修订版更改的继承是Accurev中的主要概念.)同时,您正在针对ChildStream1中的一个供应商进行特定开发,并在ChildStream2中进行特定于另一个供应商的更改.您可以有选择地决定将ChildStream1和2中的哪些代码提升为CompanyStream,但在CompanyStream中进行的任何更改都应该是您希望在两个子流中显示的内容.如果您将代码从ChildStream1提升为CompanyStream,那么这些更改将在更新后显示在ChildStream2中(因为它再次继承了CompanyStream)
流可视化将如下所示:
CompanyStream -
| - ChildStream1
| - ChildStream2
Accurev Overlap =自您更新流后,父流中的文件已被修改.可视化父流在您之上(这就是它在客户端中的显示方式),并且该流已经水平推进,因此它与您所处的时间点重叠.
SVN快速映射到Accurev概念:
SVN Checkin - 推广
SVN Checkout - Anchor(锚定某些内容使其成为WIP - 正在进行中)
SVN更新 - 更新
Accurev工作区
我还没有提到工作空间.工作区表示硬盘驱动器上的代码.工作空间类似于流,因为它可以具有历史记录,并且可以跟踪您所做的更改.(这就是Keep的作用 - 它在您的工作区历史记录中存储您在Keep操作期间指定的文件的快照.您可以随时恢复到这些文件快照.因此,工作区也可以被视为您的自己的个人私有流,它是对代码内所做更改的记录.)
流是表示修订更改的抽象概念,以及已发生的事件的历史.流和工作空间从其父流继承代码.但是,与流不同,工作空间不能具有子流或子工作空间.工作区就像树上的叶子; 溪流就像树枝.
您升级为流.你保持工作区.所有可以看到流的人都可以看到提升的更改.保持更改仅对您(工作区的所有者)可见.
Kept文件将在您的工作区中有快照(如果您想要还原它们).提升的文件将在您将其提升到的流中具有快照(可以这么说).最大的区别在于,提升的更改将逐渐渗透到继承该流的任何流或工作空间.
然后他们只会在你的工作区.此外,我相信当您进行推广时,Accurev会先保留(因此您可以在工作区和要推广的流中记录文件更改).
你能给我举个例子吗？我对Accurev的文件版本控制的掌握有点模糊.我相信版本属性将由工作空间或流分配,从中提升最近的更改(不是保留).有可能存在一些流继承关系,这些关系会导致文件具有在您将其追踪之前看起来不正确的属性.
然后做一个反对"支持"的差异,而不是反对基础.
对我有用的简单配置是:我总是从一些公共开发流创建自己的个人私有流.然后,当我想要进行更改(或者能够恢复)时,我会升级到自己的流.我一直在我的工作区工作,如果我想把我的工作区与我之前做过的事情或我上面发生的事情(其他人做出的改变)区分开来,我会对Backed做一个差异.
对不起,这么久.希望它有帮助......
小智 6
由于其他几个人试图回答你的直接问题 - 戴夫的回答是最简洁和准确的 - 我会用你的子弹刺伤:
当我"保留"某些文件然后"推广"它们时会发生什么？
保留文件将创建该文件的新版本,仍然是您工作区的私有版本.非常适合自动编码,创建转移点,只是简单的私人开发.您可以在将来的任何时间恢复到任何以前保存的文件版本,无论是您自己还是来自任何其他贡献者.当你对当前的版本感到满意(你已经编译,构建,测试,等等),你可以将它推广到你的父流中,从而将其他人暴露给你的版本,而不会有你在提交时破坏的风险在登记入住时间.
如果我不提升我刚刚保存的相同文件怎么办？
同样,总工作空间自治.如果您是那种可以跟踪您正在做的事情的开发人员,那么您可以同时处理100个文件.你可以推广没有,全部,一个,一些 - 并不重要 - 你可以在时间轴上做到这一点.
当非冲突(即重叠)更新发生时,为什么历史有时会被错误归因？特别是这让人想起Subversion的失败模式,从我听过的基本解释来看,我认为Accurev不应该存在.
不确定我具体知道你在这里指的是什么.在AccuRev工作区中运行更新时,它将永远不会覆盖您正在进行的工作.如果你在,否则将被继承元素的工作 - 这意味着在你的父层次结构中的内容发生了变化 - 它们将被列在您的工作空间(重叠).同样,您可以选择何时执行合并,并仍然从上面更新其他更改,甚至继续处理冲突文件.合并发生在工作区中,而不是在推动的时候,让你再一次编译,生成,结果在其他地方交付之前测试的选项.
为什么差异几乎从不包含我期望的那些？我相信发生的事情是,基于差异的差异向我展示了当前(移动)父流的差异,但我真正想要的只是看到自我上次更新以来我所做的改变.
Diff against Basis将向您显示工作区中的版本与您上次从更新或工作区创建继承的版本的比较.Diff against Backed将显示您的版本与父流中当前的版本进行比较的方式.因此,如果有人在您仍在进行中的情况下提升了对该文件的更改,则Diff against Basis将仅与原始文件进行比较,而Diff for Backed则与父项中的新内容进行比较.顺便提一下,在History - > Browse Versions视图中,您可以将文件的任何两个版本相互区分.
希望这可以为您的具体问题提供一些观点.