2017-06-14 106 views
1

在我的工作场所有一个大型的svn仓库(+80.000版本)和大量的二进制文件。我正在尝试使用git-svn,但克隆整个历史似乎是不切实际的(它需要超过100 GB并且将近一周才能完成整个过程)。在git-svn中处理大型仓库与二进制文件

我试过克隆修订版的一个子集(最后~10.0000),并且工作得很好。这种方法的主要缺点是,责任只限于我提取的最旧版本。

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

+1

你应该看看Git LFS。 –

+0

[Git with large files]可能重复(https://stackoverflow.com/questions/17888604/git-with-large-files) –

+0

@OliverCharlesworth和@PeterReid你读过这个问题了吗?这是关于'git-svn',原则上不是关于Git中的二进制文件。 – Vampire

回答

0

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

不幸的是,解决方案并不能做你想象中的事情(尽管我最初也是这么想的)。解决方案是重构存储库,从源中分离二进制文件。这说起来容易做起来难,因为你需要让你的部门加入,影响你的团队的工作流程,但是如果你能把它取消,那将是值得的。

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

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

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