Accurev 性能如何？

Question

当前版本（4.7）的性能如何 阿库列夫?

• 每 100mb、每 GB 的结账时间？
• 每 # 个文件或 mb 的提交时间？
• 当 100+ 流时 gui 的响应能力？

我刚刚进行了 Accurev 的演示，这些流看起来像是一种围绕代码/项目建模工作流程的轻量级方法。我听到人们称赞 Accurev 的流后端并抱怨其性能。Accurev 似乎对性能进行了研究，但我想获得一些真实世界的数据，以确保这不是演示-运行良好-运行较差的情况。

有人有 Accurev 性能轶事或（甚至更好）测试数据吗？

Answer 1

我没有任何数字，但我可以告诉您我们在哪里注意到了性能问题。

我们的构建通常使用源代码管理中的 30-40K 文件。目前，我的工作区中有超过 66K 个文件，包括构建中间文件和输出文件，大小超过 15GB。为了保持 AccuRev 快速响应，我们积极使用 忽略元素 因此 AccuRev 会忽略任何中间文件，例如 *.obj。另外我们使用 时间戳优化. 。一般来说，运行更新很快，但项目规模通常为 5-10 人，因此如果每天更新，通常只会删除几十个文件。即使有人进行了涉及大量文件的更改，速度也不是问题。另一方面，完全填充所有 30K+ 文件的速度很慢。我没有时间，因为我很少这样做，而且在极少数情况下，我会在去吃午餐或开会时运行填充。我预计最多可能需要 10 分钟。一般来说，源文件下载得很快，但我们有一些大的二进制文件，10-20MB，每个文件需要几秒钟。

如果排除规则和忽略元素配置不正确，AccuRev 可能需要几分钟的时间来运行此大小的工作区的更新。当我听到其他开发人员抱怨速度时，我知道有些东西配置错误，我们会解决它。

大约一年前，其中一个项目更新了 boost 超过 25K 个文件，并将 FireFox 添加到存储库中（忘记了大小，但使 boost 看起来很小）。他们还添加了 ICU，编写了大量软件并修改了无数文件。我记得流中大约有超过 250K 个文件。不幸的是，我决定将他们所有的好代码提升到根目录，以便所有项目都可以共享。事实证明，这有点超出了 AccuRev 的处理能力。推动所有变更是一个持续数小时的过程。我记得 FireFox 推广后，其余的一切都很顺利 - 也许是一个包含超过 100K 个文件的事务是问题所在？

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

至于流的数量，我们有超过 800 个流和工作区。这里的性能不是问题。一般来说，我发现大量的流很难导航，因此我只运行我的工作区和我感兴趣的流的过滤视图。但是，当我需要查看未过滤的列表以查找某些内容时，性能就很好。

最后一点，AccuRev 支持是 了不起 - 我们称它们为天空中的声音。我们时常使用 AccuRev 搬起石头砸自己的脚，最终却对如何解决问题一无所知。几乎我们总是做了一些愚蠢的事情，然后尝试一些更愚蠢的事情来解决它。最终我们提出了支持请求，接下来我们知道他们通过电话或转到会议引导我们完成正义的步骤。我什至曾因一些琐碎的事情联系过他们，因为我忙了一天，所以我没有时间去解决这些问题，他们很友善地引导我完成这些事情，而不是告诉我 RTFM。

Answer 2

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

原文评论：这个答案适用于Accurev的任何版本，而不仅仅是4.7。首先，如果您可以使用 Web 客户端，GUI 性能可能还可以。如果您无法使用 Web 客户端并且想要 GUI 性能，那么您最好使用 Windows，或者将所有开发人员集中在一处，即Accurev 服务器所在的位置。尝试通过 WAN 在 X-Windows 上运行 GUI 吗？忘了它 ：我们的经验是基本的点击操作需要几十秒或几分钟。这是通过大约 800 英里远的相当良好的 WAN 进行的，具有几乎最佳的 ping 时间。这不是 Accurev 的故障，而是 X-Windows 的故障，并且您可能会在 WAN 上使用其他 X 应用程序时遇到类似的问题。因此，如果可能的话，请避免使用基本的 X。目前我们不能，并且我们的 WAN 用户被强制降级为只能使用命令行。基本问题是 Accurev 是中心化的，你无法提高光速。我相信您可以通过运行 Accurev 复制服务器来解决 WAN 延迟问题，但如果您通过 VPN 在单人办公室有远程开发人员，那么这仍然无法正确解决问题。具有讽刺意味的是，复制服务器在某种程度上将这种集中式 VCS 转变为 DVCS 的一种形式。如果您没有复制服务器，那么一个可怕但有些可行的解决方法是使用增量同步工具（例如 rsync）在可以运行 GUI 的本地计算机（即直接在您的 Windows 或 Linux 笔记本电脑上运行的 GUI）以及您实际工作的机器（例如，1,000 英里外的 UNIX 机器）。另一种选择是使用 VNC 之类的东西，它在 WAN 上比 X 工作得更好，连接到 Accurev 服务器位置的虚拟桌面，然后从那里使用 X。在我的工作场所，不止一个团队会同时使用 Mercurial，并仅在绝对必要时才升级为 Accurev。正如 Stephen Nutt 上面指出的，其他必要的工作是使用时间戳优化并忽略。当我们需要包含大量文件时，我们的 Accurev 管理员（是的，它需要你雇人来照顾它）也会抱怨，尽管事实上它们构成了我们产品的核心部分，并且必须包含在内并进行版本控制。得出你自己的结论。