我们正在研究 Plastic SCM 作为 Subversion 的可能替代品，用于我们产品的版本控制。除了非常庞大的源代码库外，我们还有非常大量的二进制资产（主要是美术资产，但也包括一些文档、AVI 等）。只是在上面加上一个数字——我们的主干分支的 HEAD 修订版的 svn 检出需要一个多小时，并且磁盘大小约为 9 GB。
有没有人在这样的环境下对 Plastic SCM 有任何经验，或者可以向我推荐一些关于 Plastic SCM 的性能和处理大型存储库的白皮书或案例研究？谷歌搜索并没有真正改变客观研究的方式——只是 Codice 自己发布的东西。我也意识到 Perforce 在这种环境中表现得非常好——我以前用过它——但我们是一个非常小的团队，预算也同样少，而且 Codice 为小型团队免费提供了这个系统（“社区版”）。
我非常接近将它安装在测试服务器上并进行尝试......但想先发布问题，以免在其他人已经在这样的环境中尝试过时浪费我的时间。在此先感谢您的时间。
2011 年 2 月 2 日更新： 只是一个更新，以防其他人有类似的问题并正在查看这个......我在一台相当普通的 Windows 2008 Server 机器上安装了 Plastic（2.8GHz Core 2 Duo，4 GB RAM，存储库正在存储在本地网络上的 SAN 上）为 Plastic 存储库运行 SQL Server 2008 R2。颠覆修订历史的导入需要一段时间 - 不到三天 - 大约 28000 个修订。然而，从 Plastic 中重新检查一个新分支是SMOKIN'很快的 - 使用 Plastic 只需不到 4 分钟，而使用 Subversion 则需要一个多小时，如上所述。到目前为止，我们印象非常深刻！