Svn 不同的版本控制系统如何处理二进制文件？
我听说SVN比Git/Mercurial更好地处理二进制文件。这是真的吗？如果是，为什么？就我所能想象的，没有版本控制系统（VCS）能够区分和合并相同二进制资源的两个版本之间的更改Svn 不同的版本控制系统如何处理二进制文件？,svn,git,version-control,mercurial,Svn,Git,Version Control,Mercurial,我听说SVN比Git/Mercurial更好地处理二进制文件。这是真的吗？如果是，为什么？就我所能想象的，没有版本控制系统（VCS）能够区分和合并相同二进制资源的两个版本之间的更改 那么，难道不是所有的VCS都不擅长处理二进制文件吗？我不太了解特定VCS实现背后的技术细节，因此它们可能有一些优点和缺点。文本文件具有二进制文件所缺乏的自然的面向行的结构。这就是为什么使用通用文本工具（diff）比较它们比较困难的原因。虽然这应该是可能的，但当对二进制文件应用diff时，可读性的优势（我们首先使用文本
那么，难道不是所有的VCS都不擅长处理二进制文件吗？我不太了解特定VCS实现背后的技术细节，因此它们可能有一些优点和缺点。文本文件具有二进制文件所缺乏的自然的面向行的结构。这就是为什么使用通用文本工具（diff）比较它们比较困难的原因。虽然这应该是可能的，但当对二进制文件应用diff时，可读性的优势（我们首先使用文本作为首选格式的原因）将丢失
至于你认为所有版本控制系统“在处理二进制文件方面都是垃圾”，我不知道。原则上，没有理由认为二进制文件的处理速度较慢。我更愿意说，在处理文本文件时，使用VCS（跟踪、差异、概述）的优势更加明显。主要的痛点在于任何DVC的“分布式”方面：您正在克隆所有内容（所有文件的所有历史记录） 由于大多数二进制文件都不是以delta格式存储的，也不是像文本文件那样压缩的，如果您存储的是快速发展的二进制文件，那么您很快就会得到一个庞大的存储库，移动起来非常麻烦（推/拉） 例如，对于Git，请参见 二进制文件不适合VCS所能带来的功能（差异、分支、合并），在工件存储库中可以更好地管理（例如a）。
对于CVCS（集中式VCS）来说，这是不必要的，因为在CVCS中，存储库可以扮演这个角色，并且是二进制文件的存储库（即使它不是其主要角色）Git和Mercurial都可以从容地处理二进制文件。不要损坏它们，您可以将它们签入和签出。问题在于规模 源文件通常比二进制文件占用更少的空间。您可能有100K的源文件构建了100Mb的二进制文件。因此，在我的存储库中存储单个构建可能会使其大小增加30倍 更糟糕的是： 版本控制系统通常通过某种不同格式存储文件。假设我有一个100行的文件，每行平均大约40个字符。整个文件的大小是4K。如果我更改了该文件中的一行，并保存了该更改，则只会在存储库的大小上添加大约60个字节 现在，假设我编译并添加了100Mb的文件。我对我的源代码进行了更改（可能是10K左右的更改），重新编译并存储新的二进制版本。嗯，二进制文件通常差异不大，所以我很可能会在我的存储库中再添加一个100Mb大小的文件。进行一些构建，我的存储库大小会增长到几GB，而我的存储库的源代码部分只有几十KB Git和Mercurial的问题是，您通常会将整个存储库签出到系统中。我现在下载的不是几秒钟内就可以传输的几十KB的数据，而是几GB的构建和几十KB的数据 也许人们会说Subversion更好，因为我可以简单地在Subversion中签出我想要的版本，而不是下载整个存储库。然而，Subversion并没有为您提供从存储库中删除过时二进制文件的简单方法，因此您的存储库将不断增长。我还是不推荐。见鬼，即使版本控制系统允许您删除过时二进制文件的旧版本，我也不推荐使用它。（Perforce、ClearCase和CVS都可以）。这最终会成为维护的一大难题 这并不是说你不应该存储任何二进制文件。例如，如果我正在制作一个网页，我可能需要一些GIF和JPEG。将它们存储在Subversion或Git/Mercurial中没有问题。它们相对较小，可能比我的代码本身变化小得多
不应该存储的是构建对象。这些应该存储在发布存储库中，并根据需要获取。Maven和Ant w/Ivy在这方面做得很好。并且，你可以在C、C++和C ^项目中使用Maven存储库结构。在
git gcmartin@martin-laptop:~/testing123$ git init
Initialized empty Git repository in /home/martin/testing123/.git/
martin@martin-laptop:~/testing123$ ls -l
total 1252
-rw------- 1 martin martin 1279322 Jan 8 22:42 pic.bmp
martin@martin-laptop:~/testing123$ git add .
martin@martin-laptop:~/testing123$ git commit -a -m first
[master (root-commit) 53886cf] first
1 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 pic.bmp
// here is the size:
martin@martin-laptop:~/testing123$ du -s .git
1244 .git
// Changed a few pixels in the picture
martin@martin-laptop:~/testing123$ git add .
martin@martin-laptop:~/testing123$ git commit -a -m second
[master da025e1] second
1 files changed, 0 insertions(+), 0 deletions(-)
// here is the size:
martin@martin-laptop:~/testing123$ du -s .git
2364 .git
// As you can see the repo is twice as large
// Now we run git gc to compress
martin@martin-laptop:~/testing123$ git gc
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), done.
Total 6 (delta 1), reused 0 (delta 0)
// here is the size after compression:
martin@martin-laptop:~/testing123$ du -s .git
1236 .git
// we are back to a smaller size than ever...