Accurev的性能如何？

Question

Accurev的性能如何？

5

目前版本（4.7）的Accurev表现如何？

每100MB或GB的检出时间？
每个文件或MB的提交时间？
当有100个以上的流时GUI的响应能力？

我刚刚看过Accurev的演示，发现流似乎是一种轻量级的方式来建模代码/项目工作流程。我听说人们称赞Accurev的流后端，并抱怨性能问题。Accurev似乎已经致力于提升性能，但我想获取一些真实世界的数据，以确保这不是一个演示效果好，运行效果差的情况。

有没有人有Accurev性能方面的经验或（更好的）测试数据？

- Petra Kahn

传闻回答：慢。除非必须使用，否则不要使用。GUI 几乎无法使用。这仅仅是传闻，我没有任何强制性的数字来支持我所说的话。 - Martin

我刚把一个Perforce项目迁移到了最新的Accurev 6.2.3，但是我听到的很多恐怖故事似乎还没有在我能察觉到的任何方面显现出来，但是GUI非常慢，我不建议在离线状态下进行任何移动操作。我喜欢我不必检查东西，但这会带来性能成本。最大的问题是GUI中的任何操作，包括单击文件，与P4相比需要很长时间。我建议学习CLI。 - Novaterata

2个回答

0

编辑于2014年：我们现在可以使用商业版RealVNC来获得可接受的X-Windows性能。

原始评论：此答案适用于任何版本的Accurev，而不仅仅是4.7。首先，如果您可以使用Web客户端，则GUI性能可能还可以。如果您无法使用Web客户端，并且希望获得GUI性能，则最好使用Windows，或者将所有开发人员都集中在一个地方，即Accurev服务器所在的位置。尝试在WAN上运行GUI？忘记它吧：我们的经验是基本点按操作需要数十秒或数分钟。这是在距离约800英里远的一个相当好的WAN上进行的，具有几乎最佳的ping时间。这不是Accurev的问题，而是X-Windows的问题，您可能会遇到类似的问题与其他X应用程序在WAN上。因此，尽可能避免基本的X。目前我们不能这样做，我们的WAN用户被强制降级为仅限命令行。基本问题是Accurev是集中式的，你无法提高光速。我认为您可以通过运行Accurev复制服务器来避免WAN延迟，但是如果您在VPN上具有远程开发人员，那么这仍然没有正确解决问题。有趣的是，复制服务器有点将这个集中式VCS变成了DVCS的形式。如果您没有复制服务器，那么可怕但有点可行的解决方法是使用像rsync这样的增量同步工具，在您可以运行GUI的本地计算机（即直接在Windows或Linux笔记本电脑上运行GUI）和实际工作的计算机之间同步您的源树（例如，距离1000英里的UNIX机器）。另一个选择是使用类似VNC的东西，在WAN上比X更好的连接到Accurev服务器位置的虚拟桌面，并从那里使用X。在我的工作场所，有多个团队不得不在一旁使用Mercurial，并且仅在绝对必要时才提升到Accurev。正如Stephen Nutt在上面指出的那样，其他必要工作是使用时间戳优化和忽略。我们还有我们的Accurev管理员（是的，它需要您雇用人来照看它），当我们需要包含大量文件时抱怨，尽管它们是产品的核心部分，必须包含和进行版本控制。得出您自己的结论。

- Tim

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Stephen Nutt · Accepted Answer

我没有具体的数字，但是我可以告诉你我们在哪里发现了性能问题。

我们的构建通常使用来自源代码控制的30-40K个文件。目前我的工作区包括超过66K个文件，包括构建中间和输出文件，大小超过15GB。为了使AccuRev工作响应迅速，我们积极使用忽略元素，以便AccuRev忽略任何中间文件，例如*.obj。此外，我们还使用时间戳优化。一般来说，运行更新很快，但项目规模通常为5-10人，因此如果每天更新，通常只有几十个文件会下载。即使有人做出了涉及许多文件的更改，速度也不是问题。另一方面，所有30K+文件的完整填充较慢。我没有时间，因为我很少这样做，而且在我偶尔这样做的时候，我会在午餐或会议时运行填充。我认为可能需要10分钟左右。通常源文件下载非常快，但是我们有一些大型二进制文件，每个文件需要几秒钟，大小为10-20MB。

如果排除规则和忽略元素未正确配置，则对于这种大小的工作区，AccuRev运行更新可能需要几分钟。当我听到其他开发人员抱怨速度时，我知道有些配置不正确，我们会解决这个问题。

大约一年前，其中一个项目使用25K+文件更新了boost，并将FireFox添加到存储库中（忘记大小但使boost看起来很小）。他们还添加了ICU，编写了许多软件并修改了无数文件。总的来说，我记得有大约250K+个文件在流中。不幸的是，我决定将他们所有的好代码推广到根目录，以便所有项目都可以共享。结果这超出了AccuRev能够处理的范围。花费了几个小时的时间才能推广所有更改。我记得一旦FireFox被推广，其他事情就变得顺利了——也许是一个包含100K个文件的单个事务成为了问题？

最近我更新了boost，因此必须保留和推广25K+个文件。考虑到文件数量和二进制文件的大小，这需要一两分钟，但不算不合理。

至于流的数量，我们有800多个流和工作区。性能方面没有问题。总的来说，我发现大量的流难以导航，因此我运行过滤视图，只显示我感兴趣的工作区和流。但是当我需要查看未过滤的列表以查找某些内容时，性能良好。

作为最后的说明，AccuRev的支持非常出色 - 我们称他们为天空中的声音。有时候我们使用AccuRev把自己绊倒了，最后变得毫无头绪。几乎总是因为我们做了一些愚蠢的事情，然后尝试更愚蠢的方法来解决它。最终，我们提出了支持请求，下一步，他们通过电话或会议向我们展示正确的步骤。我甚至因为忙碌的一天没有时间弄明白一些琐碎的东西而联系过他们，他们很亲切地带领我完成，而不是告诉我去看文档。