在SVN中存储二进制文件的方法

您没有将Subversion设置为使用这些方法中的任何一种,而是指定将文件放入存储库时要使用的方法。我所说的“方法”,不是指你提到的4个方法中的任何一个,而是“导入”或“提交”,每次你想把文件的新版本存储到存储库中时,你都必须不断地告诉Subversion你所选择的方法。

见 Performance tuning Subversion .

从这里的描述可以看到,为了使用“方法1”,压缩到tar然后使用import,它们必须自己将所有二进制文件压缩到.tar文件中,然后使用subversion的import命令将文件添加到存储库中。

还要注意,这里的警告是,import命令将文件存储为新文件,而不是以前版本的增量,因此,如果对大文件所做的更改很少,那么它可能会节省时间,但不会节省空间。

颠覆本身只做承诺和导入。提交是对现有文件的新修订,存储为增量序列(或新文件的第一个修订,但不是),导入只是一个新文件。你还得自己做什么。

如果二进制文件只是偶尔更改,那么这可能值得进一步研究,但是如果它们是定期更改的,那么我建议您使用subversion作为普通方法,并使用commit命令。

另请注意,当涉及二进制文件时,典型的建议是,如果可能的话,将源代码存储到生成这些二进制文件的任何对象,然后重新运行工具来重现实际的二进制文件。如果二进制文件需要花费时间或空间来进行复制,那么只有这样,您才能存储有问题的二进制文件。

二进制文件存在不太好比较的问题,因此,如果开发人员A和B都检索到最新版本,然后开发人员A在开发人员B尝试执行相同操作之前提交一个新版本,则会发生某种类型的冲突。开发人员B可能别无选择,只能试着自己解决更改。

编辑 :让我强调一下我所说的提交和导入。

主要的区别是,如果您已经在存储库中保存了该文件,那么commit将尝试将工作副本中的文件与以前的存储库版本进行比较,并只存储更改。这将需要时间和内存来解决这些差异,但通常会导致存储库中出现较小的修订变更集。换句话说,与使用import命令相比,Subversion服务器上的磁盘空间受到的影响更小。

另一方面,导入将导入新文件,就像您刚给它一个新文件并说“忘记前一个文件,只存储这个文件”,因此不会花费时间或内存来解决这些差异,但存储库中产生的更改集将更大。换句话说,Subversion服务器上的磁盘空间将比commit命令受到更大的影响,但导入通常运行得更快。

您想要强制实施的任何其他工作流都必须在Subversion之外完成。这包括操作系统中可用的tar命令和压缩选项。如果您想使用“方法1”,您自己必须手动压缩要导入到单个.tar文件中的文件,然后才能将其提交给Subversion。你不能要求颠覆者为你做这些。当然,您可以让脚本文件稍微自动化流程,但这并不是一个颠覆性的问题。

我将对此做一些认真的测试,以确定这些收益是否真的值得您对您的颠覆工作流进行额外的工作。

你能详细描述一下你的情况吗?

您有几个小的二进制文件可以一起更改吗?几个独立更改的大型二进制文件?你的文件经常更改吗?

您是否发现默认值不够好?我总是以和正常一样的方式添加二进制文件,并发现它可以正常工作。像任何性能问题一样,我不会让事情变得复杂,除非你有一个很好的理由-在这种情况下,请与我们分享这个理由。