当前版本（4.7）的性能如何Accurev http://www.accurev.com?
- 每 100mb、每 GB 的结账时间？
- 每 # 个文件或 mb 的提交时间？
- 当 100+ 流时 gui 的响应能力？
我刚刚进行了 Accurev 的演示，这些流看起来像是一种围绕代码/项目建模工作流程的轻量级方法。我听到人们称赞 Accurev 的流后端并抱怨其性能。 Accurev 似乎对性能进行了研究，但我想获得一些真实世界的数据，以确保这不是演示-运行良好-运行较差的情况。
有人有 Accurev 性能轶事或（甚至更好）测试数据吗？
我没有任何数字，但我可以告诉您我们在哪里注意到了性能问题。
我们的构建通常使用源代码管理中的 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 支持是terrific- 我们称它们为天空中的声音。我们时常使用 AccuRev 搬起石头砸自己的脚，最终却对如何解决问题一无所知。几乎我们总是做了一些愚蠢的事情，然后尝试一些更愚蠢的事情来解决它。最终我们提出了支持请求，接下来我们知道他们通过电话或转到会议引导我们完成正义的步骤。我什至曾因一些琐碎的事情联系过他们，因为我忙了一天，所以我没有时间去解决这些问题，他们很友善地引导我完成这些事情，而不是告诉我 RTFM。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
