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