为产生一个4GB的ISO构建系统的版本控制解决方案 [英] Version control solution for a build system that produces a 4GB ISO

查看:161
本文介绍了为产生一个4GB的ISO构建系统的版本控制解决方案的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有在其生成的最后阶段,创建所有的jar文件和相关的脚本/配置文件后,我需要种在一个CentOS的ISO有运行一些安装后脚本的kickstart配置文件的软件项目并安装一些定制的RPM。

I have a software project that at the last stage of its build, after creating all the jar files and related scripts/configuration files, I need to plant it in a CentOS ISO that has a kickstart config file that runs some postinstall scripts and installs some customized RPMs.

该项目是在一个SVN库,并从那里正在兴建。我不能在ISO的文件插入到库中,因为SVN不处理4GB的存储库。
在另一方面,问题是,一些在ISO RPM包的可能会从版本改为版本,当我想建立该项目的旧版本我在一个不好的地方,因为这些RPM不在SVN资料库。

The project is on an SVN repository and being built from there. I can't insert the files of the iso into the repository because SVN doesn't handle a 4GB repository. On the other hand, the problem is that some of the RPMs in the ISO might change from version to version, and when I want to build an older version of the project I'm in a bad place because the RPMs are not in the SVN repository.

有没有办法,我只能使用ISO的4GB,可以处理的数据量,一个很好的版本控制解决方案?
是否有一个非版本控制解决方案,我想要做什么?

Is there a good version control solution that I can use just for the 4GB of ISO that can handle this amount of data? Is there a non-version-control solution to what I'm trying to do?

我想preFER产生尽可能对现有SVN仓库的结构变化较小,因为有许多脚本和东西依赖于它。

I would prefer to produce as less changes as possible to the existing SVN repository's structure, as there are many scripts and stuff that depend on it.

威尔AP preciate各种答案和建议。

Will appreciate all kinds of answers and suggestions.

谢谢!

推荐答案

如果你真的需要存储大量的文物(ISO,RPM,...)为其中:

If you really need to store large artifacts (ISO, RPM, ...) for which:


  • 您不必从一个版本的差异比较另一个

  • 您不需要进行平行演进(只读文物)

那么你实际上并不需要VCS(版本控制系统)。

then you don't actually need a VCS (Version Control System).

您需要的工件储存库,例如像的Nexus 。结果
请参见<一个href=\"http://stackoverflow.com/questions/3329041/best-practice-to-store-jar-files-in-vcs-svn-git/3329272#3329272\">Best实践文件存储在的.jar VCS(SVN,Git的,...)

You need an artifact repository, like for instance Nexus.
See "Best practice to store .jar files in VCS (SVN, Git, …)"

您的版本,在SVN回购一起神器库和所说的文物已被存储时所使用的必要引用它的SHA1 / MD5密钥的文本文件。

You will version in your SVN repo a text file with the necessary references to the artifact repository and its SHA1/MD5 key used when said artifacts have been stored.

这两个库的组合将让完整的重现性,同时很好地扩展(在库大小的期限),由于工件库(违背一个VCS)只受磁盘空间的限制。

The combinations of those two repositories will allow complete reproducibility, while scaling nicely (in term of repository size), since an artifact repository (contrary to a VCS) is only limited by disk space.

这篇关于为产生一个4GB的ISO构建系统的版本控制解决方案的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆