2

人们推荐使用哪些版本控制系统来管理大量主要是二进制文件？该集合包含数千个文件，总计约 8GB，并且会随着时间的推移而增长。

我们尝试了 GIT，发现执行这么多二进制比较有点慢。也许我们配置错了什么？

4

1 回答 1

6

版本控制往往被称为另一个名称......源代码控制或源代码控制。这个名字本身就暗示了它们是为什么而构建的：源代码 - 即相对较少数量的相对较小的文本文件。大多数系统可以（或至少应该）能够处理大型二进制文件的大型存储库，并取得不同程度的成功。

版本控制系统

大致有三种主要类型的版本控制工具，在存储版本控制方面，每种工具都有不同的权衡。但是，当您拥有大型二进制文件的大型存储库时，这些设计决策可能会成败。

  1. 像 CVS 和 Subversion 这样的编辑/合并/提交系统并不能很好地解决这个问题。在这些类型的系统中，当您从服务器获取代码时，文件将在您的工作目录中创建并以读/写方式创建。此外，客户端将存储一些机制来确定您是否在本地更改了这些文件 - 这可能是文件内容的哈希值，因为它们存在于服务器上，或者它可能是未经编辑的“基线”文件的副本。当您想确定文件系统上发生了什么变化时，您的版本控制客户端会将您的工作目录与基线进行比较，以告诉您您编辑了哪些文件。

    这些类型的系统往往不能很好地扩展到具有多 GB 文件的多 GB 存储库。如果您对自己的使用模式非常小心，某些工具可能还可以 - 例如，您可以通过避免使用 UI 前端来限制这些工具的范围，而是显式提供您要签入的路径（而不是扫描整个工作目录。）

    此外，如果您选择使用整个基线文件的工具，您将需要双倍的磁盘空间 - 8GB 用于您的资源，另外 8GB 用于基线文件。

  2. 像 git 和 mercurial 这样的分布式版本控制系统也不太可能是这里表现最好的。DVCS 工具的历史模型与集中式编辑/合并/提交系统完全不同，但大多数工具的相似之处在于，当您想要确定工作目录的状态时，它们会比较目录中的文件以查看发生了什么变化。

    在这里，您的磁盘空间需求也会增加。由于分布式系统在本地存储存储库的副本，因此存储库至少需要与工作文件夹一样多的空间 - 这是最好的情况，并假设您的系统支持“浅”历史，其中它不会存储文件的所有历史版本。

    一些 DVCS 工具具有二进制或“大文件”模式或插件，其中大文件放置在中央服务器而不是本地存储库中。这种混合方法肯定有其优点，尤其是当您并不总是需要那些大文件时。否则，您可能会遇到集中式版本控制系统的所有复杂性与 DVCS 的所有复杂性相结合的情况。

  3. 像 Team Foundation Server 和 Perforce 这样的签出/编辑/签入系统可能是最合适的版本控制系统。在这些类型的系统中，当您从服务器获取代码时，文件将在您的工作目录中创建并设置为只读。这是因为您将在开始编辑这些文件时指示该工具，此时您的客户端会将它们设置为读写。然后，您的客户端（或服务器）会维护您所做更改的列表。完成编辑后，您可以将它们签入服务器。

    当您拥有非常大（多 GB）的存储库和/或非常大（多 GB）的文件时，这些类型的系统是有利的，因为您不必检查工作文件夹中的更改或差异文件。

    请注意，某些系统可能能够在任一模式下工作。例如，TFS 2012 默认使用编辑/合并/提交模型（称为“本地工作空间”），但可以明确使用检出/编辑/签入模型（称为“服务器工作空间”）。

（注意，我在这里借用了Eric Sink 的术语，但考虑到他写了一本关于版本控制系统的书，我认为这些是适当的权威。）

数字资产管理

如果您的多 GB 文件的大型存储库碰巧不仅仅是随机数据，而是......图形或音频，那么您最好完全避免使用版本控制系统并瞄准专门为此设计的数字资产管理工具目的。

其中一些工具（如 Quark Publishing System 和 K4）针对出版业，一些（如 Adob​​e VersionCue）针对图形设计和插图行业。其中一些工具（如 Alienbrain）甚至具有 Visual Studio 插件，以试图吸引从事繁重图形和音频工作以及编写代码的游戏开发工作室。

如果您碰巧从事游戏开发工作，那么在游戏开发网站上有几个很好的回答这个问题。

于 2012-09-07T19:06:50.587 回答