Version Control / Configuration Management for Linux Images

Question

One project I'm working on involves continuously maintaining a base Linux disk image that gets cloned onto embedded devices.

Right now, every time a change is made, we log what we've done in a file and save a copy of the disk image. As a software engineer, however, this flies in the face of conventional practice: using tooling to handle configuration management and control.

Is there good tooling out there that can basically do this at a file level, allowing us to commit/rollback changes to the actual files on the disk for the entire system? Or alternatively, is there something that can handle a huge file better than traditional source code management tools, which aren't exactly designed for giant binary files?

Answer 1

We ended up putting key files in source control but not the entire system.

Answer 2

Five years after my comments, I have a far better solution. Artifactory and Nexus are intended to do this exact job as part of a CI/CD code pipeline.

In my case, I use Jenkins, Artifactory, GitHub, CircleCI, and for legacy reasons Perforce, to manage a code tree of 70k+ files ( code tree not my design!) for a C++ and Javascript build.

FOSS Artifactory is quite limited, you can store arbitrary files with version control, but you can't use the step-forward mechanism that lets you control the Pipeline as it moves artifacts from build to test to...deployment.

Artifactory Pro is not free, but it has repos for many standard packages, such as Docker containers, Debian, NPM, Gems and so forth.

Answer 3

Configuration management should be done in the preferred form for making modifications. For a disk image, that means the actual files, together with a build script for building the image. The reasoning behind this has to do with the reasons you keep a history in the first place:

• Determine in what revision a bug or feature was introduced, and by whom
• Check out a previous revision to debug a field issue, maybe adding temporary debug code to it
• Be able to make branches for various reasons, and merge them together when appropriate

Since a disk image can be extracted, you're not completely stuck if you just track the binary, but those actions are a lot easier by tracking the source.

Answer 4

I have exactly the same problem. at the moment my repository for releases is over 150G in git, moved from CVS. CVS handled small files perfectly, but balks at multi-G files. So. in case anyone else drops by, here are some possible solutions I am looking at:

http://git-annex.branchable.com/

https://github.com/jedbrown/git-fat

https://github.com/schacon/git-media

http://code.google.com/p/boar/

And possibly Subversion, if it can handle 8G files.