Version control solution for a build system that produces a 4GB ISO

Question

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!

Answer 1

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.

Answer 2

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

Answer 3

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?

Answer 4

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.

Answer 5

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.