我们正在研究 Plastic SCM 作为 Subversion 的可能替代方案，用于我们产品的版本控制。除了非常庞大的源代码库之外，我们还拥有大量的二进制资产（主要是艺术资产，还包括一些文档、AVI 等）。简单说一下 - svn 检查我们的 trunk 分支的 HEAD 版本需要一个多小时，磁盘大小约为 9 GB。
有没有人在这种环境下有塑料 SCM 的经验，或者可以向我推荐一些有关塑料 SCM 的性能和大型存储库处理问题的白皮书或案例研究？谷歌搜索并没有真正改变客观研究的方式——只是 Codice 自己发布的东西。我还意识到 Perforce 在这种环境中表现得非常好 - 我以前用过它 - 但我们是一个非常小的团队，预算同样很小，并且 Codice 为小型团队免费提供这个系统（“社区版”）。
我非常接近将其安装在测试服务器上并尝试一下......但想先发布问题，以免如果其他人已经在这样的环境中尝试过，就不会浪费我的时间。在此先感谢您的时间。
2011 年 2 月 2 日更新：只是一个更新，以防其他人有类似的问题并正在查看此内容...我将 Plastic 安装在一台相当普通的 Windows 2008 Server 计算机上（2.8GHz Core 2 Duo，4 GB RAM，存储库存储在本地的 SAN 上）网络）为 Plastic 存储库运行 SQL Server 2008 R2。 Subversion 修订历史记录的导入需要一段时间 - 不到三天 - 约 28000 个修订。然而，它是SMOKIN'快速对 Plastic 的新分支进行全新检查 - 使用 Plastic 仅需不到 4 分钟，而如上所述，在 Subversion 上则需要一个多小时。是印象非常深刻 so far!
我们正在从 Perforce 转向 Plastic，我们的存储库约为 360Gb，
所以也很大。即使使用巨大的文件，它实际上也可以无缝运行。
由于我们身处视频游戏行业，因此大文件是必须的，并且
您知道所有其他 DVCS（Hg、Git）在处理它们时都存在问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
