用于生成 4GB ISO 的构建系统的版本控制解决方案

发布于 2024-09-13 20:44:03 字数 423 浏览 3 评论 0原文

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

该项目位于 SVN 存储库上并从那里构建。我无法将 iso 文件插入存储库,因为 SVN 无法处理 4GB 存储库。 另一方面,问题是 ISO 中的一些 RPM 可能会随着版本的不同而改变,当我想构建项目的旧版本时,我的处境很糟糕,因为 RPM 不在 SVN 中存储库。

是否有一个好的版本控制解决方案,我可以使用 4GB ISO 来处理如此大量的数据? 对于我想要做的事情是否有非版本控制解决方案?

我希望对现有 SVN 存储库的结构进行尽可能少的更改,因为有许多脚本和内容依赖于它。

将感谢各种答案和建议。

谢谢!

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.

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.

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?

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.

Will appreciate all kinds of answers and suggestions.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

莫言歌 2024-09-20 20:44:03

如果您确实需要存储大型工件(ISO、RPM...),为此:

  • 您不需要比较一个版本与另一个版本的差异,
  • 您不需要进行并行演化(只读工件)

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

您需要一个工件存储库,例如 Nexus
请参阅“存储 .jar 的最佳实践VCS 中的文件(SVN、Git、...)

您将在 SVN 存储库中对文本文件进行版本控制,其中包含对工件存储库的必要引用以及存储所述工件时使用的 SHA1/MD5 密钥。

这两个存储库的组合将允许完全的可重复性,同时可以很好地扩展(就存储库大小而言),因为工件存储库(与 VCS 相反)仅受磁盘空间的限制。

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

  • you don't need to compare the differences from one version to another
  • you don't need to make parallel evolutions (read-only artifacts)

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

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

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.

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.

不再让梦枯萎 2024-09-20 20:44:03

如果您需要可重现的构建输出,那么您需要对整套构建输入进行版本控制。这包括 RPM,或者至少包括其版本的清单(如果可以从某处可靠地获取它们)。保存生成的 ISO 是徒劳的。

If you need reproducible build outputs, then you need to version the complete set of build inputs. That includes the RPMs, or at least a manifest of their versions if they can be reliably obtained from somewhere. Saving the generated ISO would be an exercise in futility.

憧憬巴黎街头的黎明 2024-09-20 20:44:03

我想你可以查看 GIT (http://git-scm.com/) - 免费,或 Perforce (http://www.perforce.com)(费用)。我认为两者都可以处理其存储库中的 4GB 文件。

I guess you can either check out GIT (http://git-scm.com/) - free, or Perforce (http://www.perforce.com) (costs). I think both can handle 4GB files in their repositories.

谈情不如逗狗 2024-09-20 20:44:03

那么吉特呢? (http://git-scm.com)

What about git? (http://git-scm.com)

为你鎻心 2024-09-20 20:44:03

为什么必须在版本控制中存储 ISO 或 RPM?

为什么不存储可以重建您需要的 ISO 和 RPM 的脚本和/或配置?

Why do you have to store the ISOs or RPMs in version control?

Why not store the scripts and/or configs that can rebuild the ISOs and RPMs you need?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文