我对在集群文件系统上使用 CVS 并由多台服务器访问它的任何经验感兴趣。我猜这类似于 SourceForge 等提供商的做法。
目前我们在 SAN 上使用基于 RHEL 的 CVS 服务器和 ext3 存储库文件系统。
这个想法是使用多台机器来处理来自客户端的 CVS 连接，这些客户端都在快速 SAN 上的同一文件系统上工作。这种冗余可以用于负载平衡和故障转移（例如，使用可以在其中一台服务器发生故障时重新配置的循环 DNS）。
由于各种原因，SVN 不是一种替代方案，请不要发起 CVS/SVN 讨论。
答案1
您在问题中给出的答案是 VCS 扩展问题的最佳答案。不要使用 CVS。不过我同意您的观点，SVN 无法解决任何问题。市面上有许多高度可扩展的版本控制系统（例如 Perforce、Rational）。
我认为，尽管你会发现集群文件系统无法提供你想要的性能，但它们的主要目标是可用性。如果你需要选择任何集群文件系统，那么我认为你需要考虑类似 http://oss.oracle.com/projects/ocfs/它是为高性能数据库集群而构建的。但是，高性能数据库并不像 CVS 那样依赖 flock 或类似的文件锁定机制，它无法扩展。您需要添加某种事务分布式锁管理器。CVS 和高性能根本不在一个水平上。
不过，我确实觉得您不是在尝试扩展源代码控制系统，而是在尝试将 CVS 用于特定于应用程序的用途。在这种情况下，我建议直接对 RCS 进行编码，并推出自己的锁管理器。我会避免分布式或集群文件系统的复杂性和昂贵性，并专注于使用某种分布式哈希桶方法构建更智能的应用程序。
答案2
在 SAN 和运行 CVS 的机器之间，您将需要某种形式的网络文件系统（至少，我想不出任何文件系统可以处理对同一设备的并发访问，我假设 SAN 是指作为存储设备呈现给服务器/操作系统的存储）。几年前，有一场关于通过 NFS 进行 CVS，您可能会遇到与任何网络文件系统相同/类似的问题。
- 您需要一个能够很好地处理锁的网络文件系统
- 理想情况下，你还需要一个网络文件系统来处理 CVS 前端之间的文件系统缓存一致性
现在，我不清楚 sourceforge 是如何为 CVS 构建的，但我的猜测是这样的：
- 少数允许 CVS 提交的盒子，可能以这样一种方式进行分区，即一个项目与一个进行提交的盒子/文件系统相关联。
- 然后，CVS 提交框的状态被复制到大量的框/文件系统，它们对它们进行负载平衡并处理匿名 CVS 读取、CVS->html 浏览等的故障转移。
（我猜测的原因是匿名 CVS 有时会提供几个小时前的 CVS 状态，并且我依稀记得 sf CVS 提交框有时会爬行得非常慢）。
答案3
我确实没有答案，但为了进一步讨论......
我假设 CVS 使用某种事务数据库作为后备存储（我知道 SVN 就是这样做的）。如果是这样的话，在我看来，这些文件结构上的多个写入器实际上并不安全。更好的方法难道不是在数据库接口上创建抽象层吗？例如，使用 SQL 服务而不是本地 BDB/LDBM 或任何其他服务（假设 CVS 支持这种服务）。