当项目树具有二进制文件时,Git、Mercurial、SVN或其他版本控制工具是否可以正常工作?

一般来说,版本控制系统对文本文件工作得更好。整个合并/冲突概念实际上是基于源代码的。然而,对于二进制文件,SVN工作得很好。(我们使用它来编辑CAD图纸。)

我将指出,当有多个人在处理一个通用的二进制文件时,文件锁定(svn:needs lock)几乎是必须的。如果没有文件锁定,两个人可以同时处理一个二进制文件。有人先提交更改。猜猜那个没有承诺的人会发生什么。他们所做的所有二元/不可计量的工作实际上都丢失了。文件锁定将对文件进行序列化。您确实失去了版本控制系统的“并发”访问功能,但是您仍然具有提交日志、回滚到以前的版本等优点。

Tortoiesvn客户机足够智能,可以使用MS Word的内置合并工具来区分文档/文档x文件。它还具有配置选项,允许您基于文件扩展名指定备用的diff工具,这非常酷。(可惜没有人为我们的CAD软件包制作不同的工具)。

但是,像git或hg这样的当前一代dvcs倾向于使用二进制文件。它们没有任何类型的文件锁定机制。

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

如果您想要提交这些文档,可以考虑提交未压缩的变体——RTF而不是DOC,TEX而不是PDF等。如果版本控制系统使用压缩来压缩其内部存储库,那么这个方法应该工作得相当好。例如,在 Git ,

新添加的对象使用zlib压缩整体存储。

编辑: 我只是想指出,即使是RTF也是可怕的,但没有医生那么可怕。如果您可以切换到TXT或TEX文件,那将是最好的。

我一直在使用Git在Mac、Linux和Windows机器之间同步我的文档。我必须做一次重新设计,以避免Windows上的2GB文件限制。在3个定期同步的存储库中,总容量约为7GB。在某个时刻,我甚至在某个地方的因特网上的主机服务器上有一个远程拷贝。

现在我几乎不需要克隆这些回购协议,这样大的规模就不会妨碍很多。我还看到.git没有显著增加,它仍然是签出文档、PDF和Excel表大小的40-60%。

在DocotPDF文件中更改一行,随着格式效果的波动,文件中的内容会发生很大的变化。同样,更改XLS文件中的单元格也会更改许多其他单元格。

但是,与没有文档在版本控制下的替代方案相比,我很高兴能够活在低于恒星压缩比的环境中。

见 mercurial wiki page about Binary files . 您的主要问题是,即使是文件中的微小更改(如Doc和其他文件)也会触发文件结构中的大更改(部分原因是压缩了文件结构)。

因此,我不相信您会找到任何在版本控制系统中处理这些文件的好方法。

imho,您应该停止使用SCM来管理这样的文档。您应该使用专用工具,如Alfresco(我确信还有许多其他的文档管理工具)。