Accurev SCM

Accurev是一种反敏捷的工具：

1. Accurev的主要思想是为不同的团队使用不同的流，因此，团队1所做的更改不会影响团队2。
   
   听起来很不错，但在现实世界中，我们都知道最终必须合并两个团队的代码，相信我，在Accurev中这是一场噩梦。两个团队在它们的数据流中所做的更改越多，每个人花费在合并上的时间就越长。
   
   如果每个团队都在单独的分支中进行开发，并尝试在1个月的开发后合并所有内容...基本上，Accurev创造了延迟合并的代价，如果你选择将其用于超过1个团队，你将永远支付这个代价。

2. 为了解决第1点所创建的问题，人们决定放弃跨职能团队而转向功能性团队。他们甚至提出了支持这种想法的论点，比如“知识专业化”原则。
   
   换句话说，当你没有跨职能团队（以及敏捷团队）时，更容易拥有特定系统部分的专家，因此他们将更好地执行代码审查，并充当“信息/设计/实现专家”。
   
   我们都知道，信息专家不仅在敏捷中是反模式，因为最好在开发中传播专业知识以避免知识瓶颈。

我站在反对Accurev的阵营。我们最近转向使用它，但是效果非常糟糕。我们有很多大型项目，但由于文件数量太多，Accurev似乎几乎无法使用。通过VPN连接，更不用说了。更新需要很长时间，跨流程管理没有直观的方式，用户界面复杂而缓慢。
此外，我们使用的许多工具都不支持或实现得很差。
加上经常出现的各种错误，我认为我们浪费了很多钱去购买一个开源软件如Subversion等可以更好地完成的东西。我们仍然使用CVS来处理一些项目，即使对于正常操作和工作流程，它也比Accurev好得多。

又一次，Accurev被大力批评。每一个简单的操作都变得异常复杂——晦涩难懂的错误信息只能让你四处寻找手册，却只找到那些本应该不存在的理论概念的解释。
用户界面反应极慢，让人想要剜出自己的眼睛。
建议远离此软件。

Accurev有一些很好的概念，但存在以下问题：
1）命令行界面中存在许多不一致性。
2）应用程序/界面中存在许多错误和麻烦。例如，由于影响快照和传递流的多个错误，其时间安全属性实际上根本不是时间安全的。
3）极其重要特性中存在重大错误...如上所述，时间安全错误和按问题合并的错误。
4）市场营销非常出色，但产品并未达到营销炒作的水平。
5）每个版本都存在重大关键漏洞，需要立即发布热修复补丁。这给我们带来了重大干扰。而这些不是小问题。
6）无法很好地扩展...占用了大量磁盘空间，并随着时间推移变得越来越慢。
话虽如此，它仍然是一个好产品，但如果我可以重新选择，我会考虑git。

经过4个月的使用，我对Accurev仍然持非常消极的看法。虽然Accurev有一些非常好的概念，但是它的缓慢和复杂性远远超过了优点，至少对我们来说是这样。除了通常关于GUI和一些功能的晦涩难懂的抱怨之外，绝对最令人烦恼的问题之一是在更新工作区时需要跳过多少环节，更糟糕的是无法只更新一个目录（或目录树）。
一个典型的更新包括等待很长时间，然后被告知存在重叠。当然，你不会被告知哪些文件发生了重叠。所以，你必须进行重叠搜索，再次等待很长时间，解决重叠问题，再进行另一个更新，再次等待很长时间，希望这次可以成功。
我们的一些远程开发人员尽可能地少更新，因为通过VPN更新的时间太长了。当然，我们有大量的源文件跨越多个产品，如果我们重新组织一切，我们可能可以改进性能。
然而，我们雇用Accurev（花费相当高）来告诉我们如何设置一切。结果还是不好。除此之外，我们真的不应该重新组织我们处理源代码的方式来适应源代码控制系统。它只是一个工具，而不是商业模式。
最后，我们正在尝试使用Accurev为IntelliJ编写的插件。它的表现和其他插件一样糟糕，虽然Accurev在修复插件方面非常积极，但我们不是他们的QA组，我们也没有签署成为alpha测试站点的协议（是的，它有那么多漏洞）。我们最终放弃了，并编写了我们自己的可以正常工作的插件。

Accurev是我使用过的最差的工具。

如果您正在从cvs迁移，Subversion非常好。

自2010年初以来，我们公司一直在使用Accurev，之前是StarTeam和遥远的过去中的CVS。我没有使用过CVS（当时在不同的团队），所以我没有比较，而且我从未费心去了解StarTeam。

此后，我在业余时间也尝试了SVN、Git和Mercurial（Hg）的CLI和Tortoise版本。我计划在某个时候更深入地了解Git，但我发现Hg在Windows下更直观易用。总之，就像我说的，管理层让我们使用Accurev，在作为开发人员花费了一些时间来熟悉它（GUI和CLI都有），我绝对讨厌它。

本帖早些时候有人将其总结为由读过SCM书籍但从未使用过的开发人员编写的软件...我完全同意，但你也会感到他们对GUI、高效处理等具有相同水平的经验。（事实上，我看到Accurev推出了一款基于Git的新产品“Kando”...听起来他们终于意识到他们的模型有多糟糕了。但引用一位同事的话，“我不会信任同一团队编写的任何东西”...我不禁想知道是否有一个叫做“Kandoo”的婴儿湿巾产品与之相似...）

好吧，显然我不喜欢这个产品。如果你花时间阅读了这个帖子，那么显然有很多人持类似的观点。但我也想分享一些我在过去几年中对它的抱怨--顺便说一句，如果有帮助的话，我认为我们以前使用的是v4.7，现在已经用了相当长的时间了。

我对Accurev最大的不满是它的速度和效率都非常低下。注意，我没有使用GUI这个词--我尝试了GUI和CLI--慢的部分在服务器上，所以你无论如何都会遭遇麻烦。似乎我在每一个转折处都能看到那该死的模态对话框/状态栏...我切换选项卡--哎呀！：处理中，请稍候。我重新设置流--哦等等，再等一分钟。对于“更新”，我希望它会有点慢（虽然有时当它向我推送与我拥有的文件完全相同的内容时，它会让我感到恼火）。我更改目录浏览路径...处理、处理，“哦，你想再进入一个子文件夹”...让我再处理一下。你懂的。

这是我的唯一不满吗？当然不是。

1）对于合并工具，我已经勾选了“忽略空格”选项好多年了，但我只记得它只在一个情况下有效过（例如，我们比较两个版本的JSP文件时，我把空格转换成制表符或修剪了一些尾随空格等）。为什么这是个问题？因为对于每一个想要查看真正变化的其他开发人员来说，这变得非常痛苦。如果他们不能正确地实现这一点，那就别在那里放这个该死的选项。（注意：使用WinMerge作为外部比较工具，带有适当的设置，运行得很好）。

2）我曾经遇到过这样的情况：将一个文件检入一个流中，然后需要将完全相同的文件副本放入另一个流中（使用相同的问题#），结果导致它抛出了一个脾气暴躁的错误。如果我使用错误的问题#，那么它会毫无问题地检入。这可能是个特例（也许是由于我们公司的其他糟糕流程决策导致的），但出于完整性的考虑，我还是想提一下。

3）所有的历史记录都存储在服务器上。换句话说，如果你享受等待它切换标签、创建/重新设置工作区和更新，那么当你想查看历史记录时，你会得到更多同样的体验。

4）它的排除规则不仅很糟糕，而且很差劲。在Windows下，你实际上需要创建一个环境变量，用来创建一些不想显示的文件的排除规则。它不支持正则表达式。我看到了一些其他的SCM提供了更好的方法（我喜欢Hg中使用的ignore文件。Git中也有类似的东西）——不仅支持正则表达式和全局通配符模式，而且在文件中定义它更加友好，也更容易编辑，而不是将它们放到一个环境变量中。不仅如此，而且它似乎在排除过滤器方面不是那么可靠。我们的项目定义方式是将构建文件夹放在项目文件夹下（该文件夹是受源代码控制的），尝试排除构建文件夹下的所有文件夹似乎不起作用——即使在设置规则之后，大多数文件仍然显示在我的“External”筛选器中。

5）它的检入流程（称为“Promote”）似乎也非常慢、低

我还可以继续说下去，但是我得停在这里了……因为这篇文章太长了。相反，让我用自己的方式总结一下Accurev：在我们试图快速修复问题时，不得不等待所有这些缓慢烦人的“Stat processing”等对话框之后，我为他们想出了一个新的口号：“AccuRev：当秒数很重要时，你的修复只有几分钟远。”

由于管理层不会放弃Accurev（我知道他们不会接受没有企业支持的任何东西，但我已经恳求他们考虑其他任何东西：SmartGit...Kiln...Perforce...），所以我一直在使用TortoiseHg来本地版本控制我的文件（除了Accurev之外）。这需要更多的工作量。但对于那些被Accurev困扰的人来说，它使生活变得更加轻松。您将获得：更好的差异管理——在“accurev update”之后查看和审查代码更改变得更加容易，无需等待服务器10年即可查看某些历史记录，可以直接在您和另一个开发者之间共享（假设他们也安装了它），如果您在试图脱离Accurev的合并地狱（“重叠”文件）时意外擦除了某些内容，则可以恢复/还原您的更改，如果您能让您的团队其他成员也使用它，则会获得更多好处。

编辑：忘记提到，在与我们的构建工程师交谈期间，我被告知尽管Accurev有一个Java API可供开发，但显然需要购买某种额外的许可证。我无法确认这一点，因为a）我无法在Accurev的网站上找到任何定价*，b）我非常怀疑他们会在工作中告诉我……

*有点奇怪，因为我可以很容易地找到Perforce、Kiln、StarTeam和SmartGit的某种粗略定价。当一些产品不会提前列出任何价格时，我通常会感到不安，我想这也不应该太让我惊讶，Accurev属于这一类别…

在之前的雇主那里，我们评估了Accurev和Plastic SCM。最终，我对Accurev的界面或所谓的“流”并不印象深刻。我们选择了Plastic，没有人抱怨。
@Jonathan 这些流很有趣，但我不知道任何版本控制如何在两个人同时更改同一文件中的相同代码时避免冲突。Accurev的模型很有趣，但到最后，一个漂亮干净的分支和合并以及一个易于使用的界面使Plastic成为我们的选择。Plastic的时间线视图（我忘记实际名称），显示分支/合并/签入历史记录，使从鸟瞰角度查看项目历史非常简单。

@Steveth

界面很糟糕...但流模型非常创新。

能够为一个新项目从主干流创建一个流，并有5个开发人员在其上工作，而在将该流合并回主干时没有任何形式的合并冲突，在Accurev中是前所未有的，但它在实践中运行良好。

简短回答： 使用最新的SVN服务器和SmartSVN（社区版是免费的）作为客户端。 您将不需要支付任何费用，可以获得所需一切。
详细内容： 顺便说一下，在检查期间强制执行更改管理规则的功能对于编写SVN挂钩来说非常简单。我们在几个小时内编写了大约100行代码 - 它工作得非常好，从未出现问题。它将SVN与Bugzilla集成，并强制执行规则，例如：
1.提交之前必须输入消息 2.提交之前必须输入处于“有效”提交状态的Bugzilla ID等等，您可以根据自己的需要构建自己的规则。
对我来说，Accurev似乎是市场软件...糟糕的GUI客户端...非常慢（我们不得不升级硬件才能使其实际上有效），当然...你必须为此付费！啊，是的，如果您确实使用它，则希望您不必在美国某地和印度某地之间复制服务器：）
Perforce更加稳健，但不太容易管理。无论如何，与Accurev相比，它是一种优越的产品。
VSS和类似的东西在21世纪写专业软件（通常是企业软件）时甚至不应被视为“版本控制”系统。这就像在打字机上编写报告一样；-）
如果您知道自己在做什么（使用软件），那么SVN将是您的稳健和高效解决方案。随着至少两个稳健和高效的版本控制系统（SVN / GIT）存在，很难有理由使用专有解决方案；一些原因可能是“惯性”：您拥有它，您不介意支付费用，并且您没有遇到任何重大问题 - 换句话说，它适合您。
我在任何地方都使用SVN，在它不存在时我使用CVS，在此之前...不，我不会告诉您我多老;-)
希望这有所帮助...
再见。