大型二进制文件和> 1TB存储库的版本控制？

Question

大型二进制文件和> 1TB存储库的版本控制？

Chr*_*igt 23 svn git version-control packaging

不好意思拿出这个话题再次,因为有洙许多其他已经相关的问题-但没有直接涉及我的问题.

我正在搜索的是一个很好的版本控制系统,只能处理两个简单的要求:

存储大型二进制文件(> 1GB)
支持> 1TB的存储库(是的,那是TB)

为什么？我们正在为我们的下一个大型操作系统部署重新打包几千个软件应用程序,我们希望这些软件包遵循版本控制.

到目前为止,我已经有了一些SVN和CVS的经验,但是我对两个大型二进制文件的性能都不太满意(一些MSI或CAB文件将> 1GB).此外,我不确定他们是否能够在未来2 - 5年内按照我们期望的数据量进行调整(就像我说的那样,估计> 1TB)

那么,你有什么建议吗？我目前也在研究SVN外部和Git子模块,虽然这意味着每个软件包都有几个单独的存储库,但我不确定这是我们想要的......

Answer 1

Mat*_*erg 11

看看Boar,"简单的版本控制和照片,视频和其他二进制文件的备份".它可以轻松处理大型文件和庞大的存储库.

看起来很棒！既然您显然是Boar的幕后黑手，您能告诉我我应该期望Boar与塑料SCM之间的另一个可能的区别吗？（/sf/answers/2045491801/）？我想要一个支持Windows + Linux的，版本控制，可扩散，增量，大+二进制文件的备份解决方案，到目前为止，这看起来是最好的两个选择。 (2认同)

Answer 2

Har*_*ode 6

版本控制系统用于源代码,而不是二进制构建.您最好只使用标准网络文件服务器备份磁带进行二进制文件备份 - 即使在您拥有源代码控制时基本上没有必要,因为您可以随时重建任何版本的任何二进制文件.试图将二进制文件放入源代码控制中是一个错误.

你真正在谈论的是一个称为配置管理的过程.如果您拥有数以千计的独特软件包,那么您的企业应该拥有一个配置管理器(一个人,而不是软件;-)),他们负责管理开发,测试,发布,每个客户发布等所有配置(也称为构建). .

将版本控制的定义限制为源代码是常见但不正确的.实际需要版本控制和分支,实际上与源代码带来的用例相同; 减去使用文件内分析的所有用例.SVN,GIT,HG和该团伙没有以可用的方式处理这个用例的事实并不是拒绝这种需要的理由. (21认同)
我同意这些原则.我不是很喜欢使用为代码构建的版本控制系统作为二进制文件的pimped fileshares.配置管理的问题在于它依赖于人工审查或至少是人为驱动的流程管理 - 这对提高意识并不是那么容易.版本控制系统附带的特权(更改日志,轻松访问等)在简单的文件共享上是不存在的.实际上,我希望通过技术而不是组织来引入结构 - 因为组织方法在我的公司中无数次失败 (2认同)
说"你可以随时重建任何版本的任何二进制文件"忽略了保证你有*完全*相同的工具(编译器,链接器等)和配置,以便源代码将转换为*精确*中的二进制文件一样的方法.这让我们回到OP关于如何控制大型二进制文件(例如g ++ .exe)的原始问题？ (2认同)
版本控制系统中的二进制文件不一定是个坏主意.如果您需要它并且无法从源创建它,您可能需要.不可复制的二进制文件不应该. (2认同)
投票无效，因为您的答案是错误的。版本控制是一个通用概念。也可能是二进制文件。 (2认同)
OP 显然是在谈论编译到应用程序中的源代码，而不是诸如照片和视频等之类的东西，这些东西确实在像 Boar 这样的东西中占有一席之地。请记住，这个问题已有 6 年历史了，而且随着时间的推移，情况已经发生了变化。 (2认同)

Answer 3

小智 5

老问题，但也许值得指出的是，Perforce 已在许多大公司中使用，特别是在游戏开发公司中，其中具有许多大型二进制文件的多 TB 存储库。

（免责声明：我在 Perforce 工作）

归档时间：	14 年，6 月前
查看次数：	15851 次
最近记录：	7 年，4 月前