有时我们的项目树可以有二进制文件，如jpg，png，doc，xls或pdf。只有二进制文件的一部分被更改时，GIT，Mercurial，SVN或其他工具可以很好地工作吗？当项目树有二进制文件时，GIT，Mercurial，SVN或其他版本控制工具可以工作吗？
例如，如果规范是用.doc编写的，并且它是存储库的一部分，那么如果它是4MB，编辑了100次，但仅用于1或2行，并在一年中检查了100次，那么它是400MB。
如果它是100个不同的.doc和.xls文件，那么它是40GB ...不是容易管理的大小。
我已经尝试过GIT和Mercurial，并且看到它们似乎都增加了大小的数据，即使在.doc或.pdf中更改了1行时也是如此。 GIT或Mercurial或SVN中有其他方式可以完成这项工作吗？
一般来说，版本控制系统的文本文件，更好地工作。整个合并/冲突概念实际上基于源代码。但是，SVN在二进制文件中工作得很好。 （我们使用它来版本CAD图纸。）
我会指出，当有多个人在一个普通的二进制文件上工作时，文件锁定（svn：needs-lock）是非常必要的。在没有文件锁定的情况下，2人可以一次处理二进制文件。有人首先进行修改。猜猜没有提交的人会发生什么。他们所做的所有二元/不可消除的工作实际上已经失去。文件锁定序列化在文件上工作。你确实失去了版本控制系统的“并发”访问能力，但你仍然可以获得提交日志的好处，回滚到以前的版本等。
TortoieSVN客户端足够聪明，可以使用MS Word的内置在合并工具中区分doc/docx文件。它还具有配置选项，可让您根据文件扩展名指定替代diff工具，这非常酷。 （这是一个耻辱，没有人为我们的CAD软件包制作差异化工具）。
当前代DVCS如Git或Hg往往会吸收二进制文件。他们没有任何形式的文件锁定机制。
查看mercurial wiki page about Binary files。你的主要问题是，即使文件（如doc和其他文件）的微小变化也会引起文件结构的巨大变化（部分原因是因为它被压缩）。
因此，我不相信你会发现在版本控制系统中处理这些文件的好方法。
这是一个有效的观点：将Word，Excel和Openoffice默认保存为基于xml的“bloated”格式可能会更好，因为SCM有更多的机会检测差异。 – 2010-06-06 09:20:29
@Peter Tillemans：在提交之前，至少可以用'git'设置一个钩子来在XML数据上运行'tidy';这可能会增加减少差异的机会。虽然可能需要安装'cygwin'才能在窗口下方得到'整洁'。这也假定MS格式足够一致，以便它们可以在它们被“整理”之后读取它们。 – intuited 2010-06-06 18:53:31
存在二进制diff工具，但它们没有多大帮助，因为图像的一个像素的更改或Word文档中的一个字符的更改并不对应于文件中一个字节的更改，由于压缩。因此对这种二进制数据的“好”处理是不可能的。
如果你想提交这样的文件，考虑提交未压缩的变体--RTF代替DOC，TeX代替PDF等。如果版本控制系统使用压缩来压缩其内部存储库，那么这种方法应该工作得很好。例如，在Git，
新添加的对象是使用zlib压缩存储在它们的全部。
编辑：我只是想指出，即使RTF是可怕的，但并不像可怕的DOC。如果您可以切换到文档的TXT或TeX，那最好。
Postscript是TeX的另一种选择。正如在另一个答案中指出的那样，Word可以将文件保存为XML格式，这也是可以进行区分的。 – 2010-06-06 20:11:17
我一直在使用git在Mac，Linux和Windows机器之间同步我的文档。我不得不做一次重新设计来规避Windows上的2Gb文件限制。总共大约7Gb在3个定期同步的软件库中。在某个时候，我甚至在互联网上的某个托管服务器上都有远程副本。
现在我几乎不需要克隆这些回购，所以大尺寸不会妨碍很多。我也看到.git没有显着增加，它仍然在检出的文档，pdf，excel表格大小的40-60％左右。
更改doc ot pdf文件中的一行，在格式化效果波及时会在文件中发生很大变化。同样，更改XLS文件中的单元格可能会改变很多其他单元格。
然而，没有版本控制下的文件的情形相比，我很高兴地住在一起比恒星压缩比
恕我直言，你应该停止使用SCM来管理这些文件。你应该使用像Alfresco这样的专用工具（我相信还有很多其他文档管理工具）。
对于svn +1：对二进制文件的需求锁定 – JeremyP 2010-06-08 08:39:16