在git-svn中处理带有二进制文件的大型存储库

时间:2017-06-14 13:51:11

标签: git svn git-svn binaries

在我的工作场所,有一个包含大量二进制文件的大型svn存储库(+80.000版本)。我正在试验git-svn,但是克隆整个历史似乎是不切实际的(完成这个过程需要100多GB和近一周的时间)。

我已经尝试克隆修订的子集(最后〜10.0000),并且工作得相当好。这种方法的主要缺点是责任只能达到我提取的最早的修订版。

理想情况下,我想克隆源文件的整个历史记录,并且只修复二进制文件的最后一千个修订版。这有可能吗?还有其他建议吗?

1 个答案:

答案 0 :(得分:0)

我在我的工作场所遇到过同样的问题,所以我会分享我的解决方案。

不幸的是,解决方案不是为了做你想象的事情(尽管我最初也想到了这一点)。解决方案是重构存储库,将二进制文件与源分开。这说起来容易做起来难,因为你需要让你的部门参与进来, 会影响你团队的工作流程,但是如果你能够实现这一点,那将是值得的。

实际上有三种类型的文件需要考虑:

  • 应在存储库中隔离源。这很简单,可以理解。
  • 第三方二进制文件也可以提交到存储库,但通过svn:externals导入它可以避免大量潜在的重复。这些二进制文件并不是很糟糕,因为你没有很多历史记录。
  • 生成的二进制文件(编译的输出)是迄今为止最糟糕的!这些随着每次编辑而改变,并且保持历史并没有意义。 VCS系统并不打算用于解决这个问题。一些公司喜欢提交二进制文件,因为他们可以在不编译的情况下检查最新的负载,但是会有巨大的成本。

我一直在实施的解决方案是通过单个命令在主要产品构建和打包中制作所有二进制文件。然后,我将从构建机器构建,打包和存档夜间(或按需)构建。人们可以从构建机器获取最新的二进制文件,只要这些软件包对安装友好,它比执行svn up更容易,因为你不会有这么多的更新/冲突/合并。这会使生成的二进制文件完全脱离SVN。