可扩展（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个文件 - 再次，一次全部不会很快，但每天十次1000个文件将更易于管理。

所以，一旦你有所有文件，尝试它，看看它是如何工作的。 所有这些都将在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会扩展得更好。 然后，您需要每天一次“发布”文件，您可以非常快速地标记它们并从标记运行已发布的版本