has*_*ble 18 svn git cvs version-control mercurial
我们使用SVN进行源代码修订控制,并正在尝试将其用于非源代码文件.
我们正在处理大量(300-500k)短(1-4kB)文本文件,这些文件将定期更新并需要对其进行版本控制.我们尝试在平面文件模式下使用SVN,它正在努力处理第一次提交(签入500k文件)大约需要36小时.
每天,我们需要系统能够在短时间内(<5分钟)处理每次提交事务的10k个修改文件.
我的问题:
谢谢
编辑1:我需要版本控制,因为多个人将同时修改相同的文件,并将以与程序员编辑源代码完全相同的方式进行手动差异/合并/解决冲突.因此,我需要一个中央存储库,人们可以检查他们的工作并查看其他人的工作.工作流程几乎与编程工作流程相同,只是用户不是程序员,文件内容不是源代码.
更新1:事实证明,主要问题更多的是文件系统问题,而不是SVN问题.对于SVN,即使在24小时后,提交具有50万个新文件的单个目录也没有完成.在1x5x10x10树中排列的500个文件夹中拆分相同的文件,每个文件夹有1000个文件,因此提交时间为70分钟.对于包含大量文件的单个文件夹,提交速度会随着时间的推移而显 Git似乎要快得多.会随着时间而更新.
jon*_*scb 13
截至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跟踪内容,而不是文件.
SVN适合吗？只要您没有签出或更新整个存储库,那么它就是.
SVN非常糟糕,因为提交了大量文件(特别是在Windows上),因为当您在系统上操作时,所有这些.svn目录都会被写入以更新锁定.如果您有少量目录,您将不会注意到,但所花费的时间似乎呈指数级增长.
但是,一旦提交(在块中,可能是目录目录),事情就会变得非常快.更新不需要这么长时间,您可以使用稀疏检出功能(非常推荐)来处理存储库的各个部分.假设您不需要修改数千个文件,您会发现它运行良好.
提交10,000个文件 - 再次,一次全部不会很快,但每天十次1000个文件将更易于管理.
所以,一旦你有所有文件,尝试它,看看它是如何工作的.所有这些都将在1.7中修复,因为修改了工作副本机制以删除那些.svn目录(因此保持锁更简单,更快).