当项目树有二进制文件时，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或其他工具可以做得很好吗？例如，如果规范是用.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软件包制作差异化工具）。

像Git或Hg这样的新一代DVCS往往会吸收二进制文件。他们没有任何形式的文件锁定机制。

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?

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.

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

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?

解决方案

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.)

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.

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).

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屋！