当项目树有二进制文件时,GIT,Mercurial,SVN或其他版本控制工具能否正常工作？

Question

有时我们的项目树可以有二进制文件,例如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内部还有其他方法可以完成这项工作吗？

Answer 1

通常,版本控制系统可以更好地处理文本文件.整个合并/冲突概念实际上是基于源代码.但是,SVN对二进制文件非常有效.(我们用它来版CAD图纸.)

我将指出,当有多个人在处理公共二进制文件时,文件锁定(svn:needs-lock)几乎是必须的.没有文件锁定,2个人可以同时处理二进制文件.有人先提交更改.猜猜没有承诺的人会发生什么.他们所做的所有二元/无法完成的工作实际上已经丢失了.文件锁定序列化对文件起作用.您确实失去了版本控制系统的"并发"访问功能,但您仍然可以享受提交日志,回滚到以前的版本等等.

TortoieSVN客户端非常聪明,可以使用MS Word的内置合并工具来区分doc/docx文件.它还有配置选项,让您可以根据文件扩展名指定备用差异工具,这非常酷.(遗憾的是,没有人为我们的CAD软件包制作差异工具).

然而,像Git或Hg这样的当代DVCS倾向于使用二进制文件.它们没有任何文件锁定机制.

Answer 2

存在二进制diff工具,但它们没有多大帮助,因为图像的一个像素的变化或Word文档中一个字符的变化与文件中一个字节的变化不对应,这是由于压缩.因此,这种二进制数据的"好"处理是不可能的.

如果要提交此类文档,请考虑提交未压缩的变体 - RTF而不是DOC,TeX而不是PDF等.如果版本控制系统使用压缩来压缩其内部存储库,那么此方法应该可以正常工作.例如,在Git中,

使用zlib压缩将新添加的对象完整地存储.

编辑:我只是想注意,即使RTF也很可怕,但不像DOC那么可怕.如果您可以为文档切换到TXT或TeX,那将是最好的.