人们建议管理大量二进制文件的版本控制系统是什么？该集包含数千个文件，总计约8GB，并将随着时间的推移而增长。
我们尝试了GIT，发现进行那么多二进制比较有点慢。也许我们配错了什么？
答案 0 :(得分：5)
版本控制往往以另一个名称...源代码控制或源代码控制而为人所知。这个名称本身正好表明了他们为之构建的内容：源代码 - 即相对较少的相对较小的文本文件。大多数系统都可以（或者至少应该）能够处理大型二进制文件的大型存储库，并取得不同程度的成功。
大致有三种主要类型的版本控制工具，每种版本控制工具在存储版本控制时都有各种权衡。但是当你拥有一个庞大的大型二进制文件库时，这些设计决策可能成败。
编辑/合并/提交系统，如CVS和Subversion不会很好地解决这个问题。在这些类型的系统中，当您从服务器获取代码时，将在您的工作目录中创建文件并创建读/写。此外，客户端将存储一些机制来确定您是否在本地更改了这些文件 - 这可能是服务器上存在的文件内容的哈希值，或者它可能是＆＃34;基线的副本＆＃34 ;没有编辑的文件。当您想确定文件系统上的更改时，您的版本控制客户端会将您的工作目录与基线进行比较，以告诉您已编辑的文件。
这些类型的系统往往无法很好地扩展到具有多GB文件的多GB存储库。如果您对使用模式非常小心，某些工具可能没问题 - 例如，您可以通过避免UI前端来限制这些工具的范围，而是明确提供您正在检入的路径（而不是扫描整个工作目录。）
此外，如果您选择使用整个基线文件的工具，则需要两倍的磁盘空间 - 资源为8GB，基线文件为8GB。
分布式版本控制系统，如git和mercurial也不太可能是这里表现最好的。 DVCS工具比您的集中编辑/合并/提交系统radically different history models，但大多数工具都相似，因为当您想要确定工作目录的状态时，他们会比较中的文件目录，看看有什么变化。
此处，您的磁盘空间要求也会增长。由于分布式系统在本地存储存储库的副本，因此您至少需要存储库与工作文件夹一样多的空间 - 这是一种最佳情况，并假设您的系统支持＆＃34;浅＆＃34;历史记录，不存储存储文件的所有历史版本。
某些DVCS工具有binary or "large file" mode or plug-in，其中大文件放在中央服务器上而不是本地存储库中。这种混合方法绝对有价值，特别是当你不总是需要那些大文件时。否则，您可能会遇到集中版本控制系统的所有复杂性以及DVCS的所有复杂性的情况。
Checkout / Edit / Checkin Systems ，如Team Foundation Server和Perforce可能是最合适的版本控制系统。在这些类型的系统中，当您从服务器获取代码时，将在您的工作目录中创建文件并将其设置为只读。这是因为您在开始编辑这些文件时要指示该工具，此时您的客户端会将它们设置为可读写。然后，您的客户端（或服务器）会维护您所做更改的列表。完成编辑后，可以将它们签入服务器。
当您拥有非常大（多GB）的存储库和/或非常大（多GB）的文件时，这些类型的系统是有利的，因为您不必检查工作文件夹中的更改或差异文件。
请注意，某些系统可能能够在任一模式下工作。例如，TFS 2012默认使用编辑/合并/提交模型（称为＆＃34;本地工作空间＆＃34; ），但可以使用checkout / edit / checkin模型（明确地称为＆＃34;服务器工作空间＆＃34; 。
（注意，我在这里借了Eric Sink's terminology，但考虑到他写了一本关于版本控制系统的书，我觉得这些都是具有权威性的。）
如果您的多GB文件的大型存储库不仅仅是随机数据，而是...图形或音频，那么您最好完全避免使用版本控制系统，并针对Digital Asset Management专门为此目的而设计的工具。
其中一些工具（如Quark Publishing System和K4）针对的是出版业，有些（如Adobe VersionCue）针对的是图形设计和插图领域。其中一些工具（如Alienbrain）甚至还有Visual Studio插件，试图吸引那些从事重型图形和音频工作以及编写代码的游戏开发工作室。
如果你碰巧在游戏开发方面工作，Game Development site就可以找到这个问题的几个好答案。