在集群文件系统上使用CVS的经验

VCS扩展问题的最佳答案就是您提出的问题。 不要使用CVS。 我也同意你的看法，SVN是解决没有人问题的方法。 有很多高度可扩展的版本控制系统（Perforce，Rational就是例子）。

我认为一般来说，虽然你会发现集群文件系统不会提供你正在寻找的性能，但他们的主要目标是可用性。 如果您需要select任何群集的FS，那么我认为您需要查看http://oss.oracle.com/projects/ocfs/这个为高性能数据库群集而构build的东西。 不过，高性能数据库不像CVS那样依赖群集或类似的文件locking机制，它只是不能扩展。 您需要添加某种事务性分布式lockingpipe理器。 CVS和高性能只是不适合在同一个球场。

我确实有一种感觉，虽然你并没有试图扩展你的源码控制系统，而你正在尝试使用CVS来处理某些特定的应用程序。 在这种情况下，我会build议直接编码给RCS，然后自己编译锁pipe理器。 我会避免分布式或集群文件系统的复杂和昂贵，并专注于使用某种分布式散列桶方法构build更智能的应用程序。

在您的SAN和运行CVS的机器之间，您将需要某种forms的networking文件系统（至less，我不能想到任何文件系统都会对同一设备的并发访问进行处理，而且我假设由SAN您指的是作为存储设备呈现给服务器/操作系统的存储）。 几年前，有关于NFS上CVS的讨论，你可能会遇到与任何networking文件系统相同/类似的问题。

• 你想要一个处理locking的networking文件系统
• 理想情况下，您还需要一个networking文件系统来处理您的CVS前端之间的文件系统caching一致性

现在，我不知道sourceforge是如何为CVS构build的，但是，我的猜测会是如下的一些内容：

• 一小部分允许CVS提交的盒子，这可能被分割成一个项目与一个盒子/文件系统相关联的地方。
• 然后将来自CVS提交框的状态复制到大量的盒子/文件系统中，这些盒子/文件系统负载平衡并处理匿名CVS读取，CVS-> html浏览等的故障转移。

（我推测的原因是，匿名CVS有时服务了一个已经有几个小时的CVS状态，而且我有一个模糊的回忆，告诉CVS提交框，有时候爬行非常缓慢）。

我没有真正的答案，但为了进一步讨论…

我假设CVS使用某种事务数据库作为后备存储（我知道SVN是这样做的）。 如果是这样的话，在我看来，在这些文件结构上的多个编写者不会真的是安全的。 在数据库接口上创build抽象层不是更好的方法吗？ 例如，使用SQL服务，而不是本地的BDB / LDBM或任何可能的（假设CVS支持这样的事情）。