可扩展（50万个文件）版本控制系统

Question

我们将SVN用于源代码修订控制，并正在尝试将其用于非源代码文件。

我们正在处理大量（300-500k）短（1-4kB）短文本文件，这些文件将定期更新并需要对其进行版本控制。我们尝试在平面文件模式下使用SVN，它正在努力处理第一次提交（签入500k文件）大约需要36小时。

每天，我们需要系统能够在短时间内（<5分钟）处理每次提交事务的10k个修改文件。

我的问题：

1. SVN是否适合我的目的。实际使用时，初始速度似乎太慢了。
2. 如果是，是否有一个特定的svn服务器实现很快？ （我们目前正在使用gnu / linux默认的svn服务器和命令行客户端。）
3. 如果否，什么是最好的f / oss /商业替代品

由于

---

编辑1 ：我需要版本控制，因为多个人将同时修改相同的文件，并且将以与程序员编辑源代码完全相同的方式进行手动差异/合并/解决冲突。因此，我需要一个中央存储库，人们可以检查他们的工作并查看其他人的工作。工作流程几乎与编程工作流程完全相同，只是用户不是程序员，文件内容不是源代码。

---

更新1 ：事实证明，主要问题更多的是文件系统问题，而不是SVN问题。对于SVN，即使在24小时后，提交具有50万新文件的单个目录仍未完成。在1x5x10x10树中排列的500个文件夹中拆分相同的文件，每个文件夹有1000个文件，因此提交时间为70分钟。对于包含大量文件的单个文件夹，提交速度会随着时间的推移而显Git似乎要快得多。将随时更新。

Answer 1

截至2008年7月，Linux内核git repo有大约260,000个文件。 （2.6.26）

http://linuxator.wordpress.com/2008/07/22/5-things-you-didnt-know-about-linux-kernel-code-metrics/

在这个数量的文件中，内核开发人员仍然认为git非常快。我不明白为什么它会在500,000个文件中变慢。 Git跟踪内容，而不是文件。

Answer 2

适合SVN吗？只要您没有签出或更新整个存储库，那么就是。

SVN在提交大量文件（特别是在Windows上）上非常糟糕，因为当您在系统上操作时，所有这些.svn目录都会被写入以更新锁定。如果您有少量目录，您将不会注意到，但所花费的时间似乎呈指数级增长。

然而，一旦提交（在块中，可能是目录中的目录），事情变得非常快。更新不需要这么长时间，您可以使用稀疏检出功能（非常推荐）来处理存储库的各个部分。假设您不需要修改数千个文件，您会发现它运行良好。

提交10,000个文件 - 再次，一次性不会很快，但每天10次10​​00个文件将更易于管理。

一旦你掌握了所有文件，就试试吧，看看它是如何工作的。所有这些都将在1.7中修复，因为修改了工作副本机制以删除那些.svn目录（因此保持锁更简单，更快）。

Answer 3

对于这样的短文件，我会检查是否使用数据库而不是文件系统。

Answer 4

git是你最好的选择。您可以检入整个操作系统（几十万个文件中的两千兆字节代码）并且它仍然可用，尽管初始签入需要相当长的时间，例如大约40分钟。

Answer 5

1. 对于svn“平面文件模式”，意思是FSFS我认为：

   • 确保您正在运行最新的svn。 FSFS在~1.5 IIRC中添加了分片，这将是500k文件的夜间/日差异。您运行的特定文件系统也会产生巨大影响。 （甚至不要在NTFS上考虑这个问题。）
   • 您将与许多文件事务进行IO绑定。 SVN对此不太有效，不得不在.svn /以及真实文件中使用stat文件。

2. git比svn有更好的性能，你欠自己至少比较

Answer 6

我推荐Mercurial，因为它仍然在可用性部门引导git（git越来越好，但是，呃）。

bzr在可用性方面也取得了飞跃。

Answer 7

你真的需要一个带有廉价快照的文件系统，比如ZFS吗？您可以将其配置为每5分钟保存一次文件系统的状态，以利用某种程度的更改历史记录。

Answer 8

你有什么理由需要每次提交提交10k个修改过的文件吗？如果每个用户立即检查他/她自己的文件，Subversion会扩展得更好。然后，您需要每天一次“发布”文件，您可以非常快速地标记它们并从标记中运行已发布的版本