当项目树有二进制文件时，GIT、Mercurial、SVN 或其他版本控制工具能否正常工作? [英] Can GIT, Mercurial, SVN, or other version control tools work well when project tree has binary files?

问题描述

有时我们的项目树可能有二进制文件，例如 jpg、png、doc、xls 或 pdf.GIT、Mercurial、SVN 或其他工具在只更改二进制文件的一部分时能很好地工作吗?

Sometimes our project tree can have binary files, such as jpg, png, doc, xls, or pdf. Can GIT, Mercurial, SVN, or other tools do a good job when only part of a binary file is changed?

例如，如果规范是用 .doc 编写的并且它是存储库的一部分，那么如果它是 4MB，并且编辑了 100 次但仅针对 1 或 2 行，并且在一年中签入了 100 次，那么它是 400MB.

For example, if the spec is written in .doc and it is part of the repository, then if it is 4MB, and edited 100 times but just for 1 or 2 lines, and checked in 100 times during the year, then it is 400MB.

如果它是 100 个不同的 .doc 和 .xls 文件，那么它就是 40GB……不是一个易于管理的大小.

If it is 100 different .doc and .xls files, then it is 40GB... not a size that is easy to manage.

我尝试过 GIT 和 Mercurial，发现它们似乎都添加了大量数据，即使在 .doc 或 .pdf 中更改了 1 行.在 GIT、Mercurial 或 SVN 中还有其他方法可以完成这项工作吗?

I have tried GIT and Mercurial and see that they both seem to add a big size of data even when 1 line is changed in a .doc or .pdf. Is there other way inside of GIT or Mercurial or SVN that can do the job?

附言我尝试了 Dropbox，我可以有一个 7MB 的文件，然后我突出显示 .PDF 文件中的几个地方，Dropbox 似乎能够在 1 秒内上传更改.我的上行链路只有大约 200kb/s，所以我认为 Dropbox 在区分我的文件方面做得很好.所以我们可以使用Dropbox，除非这种方式没有版本控制.

P.S. I tried Dropbox and I could have a 7MB file, and then I highlight a couple of places in the .PDF file, and Dropbox seemed to be able to upload the change in 1 second. My uplink is only about 200kb/s, so I think Dropbox did a pretty good job diff'ing my file. So we can use Dropbox, except there is no version control this way.

推荐答案

一般来说，版本控制系统在处理文本文件时效果更好.整个合并/冲突概念实际上是基于源代码的.但是，SVN 对二进制文件非常有效.(我们用它来版本化 CAD 图纸.)

In general, version control systems work better with text files. The whole merge/conflict concept is really based around source code. However, SVN works pretty well for binary files. (We use it to version CAD drawings.)

我要指出的是，当有多个人在处理一个共同的二进制文件时，文件锁定 (svn:needs-lock) 几乎是必不可少的.如果没有文件锁定，两个人可以同时处理一个二进制文件.有人首先提交他们的更改.猜猜没有承诺的人会发生什么.他们所做的所有二进制/不可合并的工作实际上都丢失了.文件锁定序列化文件上的工作.你确实失去了版本控制系统的并发"访问能力，但你仍然拥有提交日志、回滚到以前的版本等的好处.

I will point out that the file locking (svn:needs-lock) are pretty much a must-have when there are multiple people working on a common binary file. Without file locking, it is possible for 2 people to work on a binary file at once. Someone commits their changes first. Guess what happens to the person that didn't commit. All of that binary/unmergable work they did is effectively lost. File-locking serializes work on the file. You do lose the "concurrent" access capabilities of a version control system, but you still have the benefits of a commit log, rolling back to a previous version, etc.

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

The TortoieSVN client is smart enough to use MS Word's built in merge tool to diff a doc/docx file. It also has configuration options to let you specify alternate diff tools based on file extension, which is pretty cool. (It's a shame no one has made a diff tool for our CAD package).

不过，像 Git 或 Hg 这样的当前一代 DVCS 往往会处理二进制文件.他们没有任何文件锁定机制.

Current-generation DVCSes like Git or Hg tend to suck with binary files though. They don't have any sort of mechanism for file locking.

这篇关于当项目树有二进制文件时，GIT、Mercurial、SVN 或其他版本控制工具能否正常工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！