滥用版本控制

Question

版本控制是否适用于内容本质上是二进制数据文件的项目？我正在考虑的包，重量约10千兆，与大量的BMP和TGA文件。

subversion可以处理这样的事情吗？有没有可能生成某种类型的二进制补丁，允许用户只下载修改过的内容。Rsync可以是一种选择，但那就没有回头路了。我真的希望能够很容易地返回到更早的版本。

我也看了这个question，但对答案不满意

Answer 1

您的问题是一个发布管理问题，它包括：

• 构建:您能够以多快的速度重新生成部分或全部交付内容?
• packaging:该交付中存在多少个文件？

如果您的内容包含太多文件，则很难在任何远程环境中部署(即复制或同步)，这在很大程度上不是因为全局大小，而是因为事务的数量needed.

• publishing:您将交付存储在哪里，以及如何将其链接到生成它的初始开发环境?

我认为，如此大规模的交付并不是为了在VCS中发布，而是存储在基于文件系统的存储库中，使用适当的名称(或version.txt)能够识别其版本并将其链接回开发内容(在subversion中存储和标记)。

Maven就是这样一个repo的例子。

我还想指出，为交付而制作的内容应该包括有限数量的文件，这意味着：

• 将许多相关文件一起压缩为一个压缩文件
• 运行一个脚本，该脚本不仅可以执行rsynch，还可以将这些文件解压缩

Answer 2

Subversion对二进制文件使用xdelta。

http://subversion.tigris.org/faq.html#binary-files

顺便说一句。相关问题：How good is Subversion at storing lots of binary files?

Answer 3

Subversion在进行更新时只通过线路发送差异，而不是整个文件。但是，文件的初始签出确实需要下载所有文件。这基本上意味着下载10。另外，二进制文件的合并是一个噩梦，所以只要你在主/从环境中工作，其中只有一个人可以提交，其他人都是从文件，他们只能更新文件，这将非常好地工作。否则，你很可能会在一次又一次的冲突中结束。

有没有可能将10 it的内存分配给多个存储库？它们真的需要作为一个整体进行版本化吗？