version-control - Accurev 性能如何？

Question

Accurev 当前版本 (4.7) 的性能如何?

每 100 兆字节、每 GB 的结账时间？

提交每个文件或 mb 的时间？

当 100 多个流时 gui 的响应能力？

我刚刚有一个 Accurev 的演示，流看起来像是围绕代码/项目建模工作流的轻量级方式。我听说有人称赞 Accurev 的流后端并提示性能。 Accurev 似乎已经在性能方面发挥了作用，但我想获得一些真实世界的数据，以确保它不是演示运行良好的情况。

有没有人有 Accurev 性能轶事或(甚至更好的)测试数据？

Answer 1

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

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

如果排除规则和忽略元素配置不正确，AccuRev 可能需要几分钟来为这种大小的工作区运行更新。当我听到其他开发人员提示速度时，我知道某些配置错误，我们将其解决。

大约一年前，其中一个项目用 25K+ 文件更新了 boost，并将 FireFox 添加到存储库(忘记了大小，但使 boost 看起来很小。)他们还添加了 ICU，编写了大量软件并修改了无数文件。我记得总共有大约 250K+ 文件坐在一个流中。不幸的是，我决定将他们所有的好代码都提升到根目录，以便所有项目都可以共享。结果证明这有点超出 AccuRev 的处理能力。这是一个多小时的过程，插入所有的变化。我记得，一旦 FireFox 被提升，其余的就很顺利了——也许是单个事务超过 10 万个文件的问题？

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

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

最后要注意的是，AccuRev 支持是 太棒了 - 我们称他们为天空中的声音。我们时不时地使用 AccuRev 用脚射击自己，结果却对如何解决问题一无所知。几乎总是我们做了一些愚蠢的事情，然后尝试一些更愚蠢的事情来解决它。最终，我们提出了支持请求，接下来我们知道他们正在通过电话或转到 session 引导我们完成正义的步骤。我什至联系了他们一些琐碎的事情，我只是没有时间弄清楚，因为我有一个忙碌的一天，他们亲切地引导我完成它而不是告诉我 RTFM。