有时我们的项目树可以有二进制文件，例如jpg，png，doc，xls或pdf。当仅更改二进制文件的一部分时，GIT，Mercurial，SVN或其他工具能否做得很好？
例如，如果规范是用.doc编写的并且它是存储库的一部分，那么如果它是4MB，并且编辑了100次但只是1或2行，并在一年中检查了100次，那么它是400MB。
如果它是100个不同的.doc和.xls文件，那么它是40GB ......不是一个易于管理的大小。
我已经尝试过GIT和Mercurial并且看到它们似乎都添加了大量数据，即使在.doc或.pdf中更改了1行也是如此。 GIT或Mercurial或SVN中是否还有其他方法可以完成这项工作？
答案 0 :(得分：13)
通常，版本控制系统可以更好地处理文本文件。整个合并/冲突概念实际上是基于源代码。但是，SVN对二进制文件非常有效。 （我们用它来版CAD图纸。）
我会指出，当有多个人在处理公共二进制文件时，文件锁定（svn：needs-lock）几乎是必须的。没有文件锁定，2个人可以同时处理二进制文件。有人先提交更改。猜猜没有承诺的人会发生什么。他们所做的所有二元/无法完成的工作实际上已经丢失了。文件锁定序列化对文件起作用。您确实失去了版本控制系统的“并发”访问功能，但您仍然可以享受提交日志，回滚到以前的版本等等。
TortoieSVN客户端非常聪明，可以使用MS Word内置的合并工具来区分doc / docx文件。它还有配置选项，让您可以根据文件扩展名指定备用差异工具，这非常酷。 （遗憾的是，没有人为我们的CAD软件包制作差异工具。）
然而，像Git或Hg这样的当代DVCS往往会吮吸二进制文件。它们没有任何文件锁定机制。
答案 1 :(得分：5)
存在二元差异工具，但它们没有多大帮助，因为图像的一个像素的更改或Word文档中一个字符的更改与文件中一个字节的更改不对应，由于压缩。因此，这种二进制数据的“好处理”是不可能的。
如果要提交此类文档，请考虑提交未压缩的变体 - RTF而不是DOC，TeX而不是PDF等。如果版本控制系统使用压缩来压缩其内部存储库，那么此方法应该可以正常工作。例如，在Git中，
使用zlib压缩完全存储新添加的对象。
编辑：我只想注意即使是RTF也很可怕，但并不像DOC那么可怕。如果您可以为文档切换到TXT或TeX，那将是最好的。
答案 2 :(得分：3)
请参阅mercurial wiki page about Binary files。您的主要问题是，即使文档和其他文件等文件发生微小变化，也会导致文件结构发生重大变化（部分原因是它被压缩）。
因此，我不相信你会发现在版本控制系统中处理这些文件的好方法。
答案 3 :(得分：3)
我一直在使用git在Mac，Linux和Windows机器之间同步我的文档。我不得不重新设计一个以逃避Windows上的2Gb文件限制。在3个存储库中总共约7Gb，这些存储库经常同步。在某个时刻，我甚至在互联网上的托管服务器上有一个远程副本。
现在我几乎不需要克隆这些回购，因此大尺寸不会妨碍很多。我也看到.git没有显着增加，它仍然是签出的文档，pdf，excel表大小的40-60％。
更改doc ot pdf文件中的一行，随着格式化效果的影响，文件会发生很大变化。同样，更改XLS文件中的单元格可以更改许多其他单元格。
然而，与没有版本控制下的文档的替代方案相比，我很高兴能够使用低于恒星的压缩率
答案 4 :(得分：1)