How far do you take version control? [closed]

Question

The theory that "disk" is cheap has gotten a bit out of hand lately. There are some powerful aspects of version control that have enabled us to onboard new developers with a few bootstrap files and one simple command to pull the toolchain over.

Recently upgrades to the systems have prompted requests for storing built binaries. This has been followed on by a request to version the entire virtualized build system. Each layer added on top creates important relationships between repositories and a good fundamental design is necessary to manage it.

The storing of the toolchain brought instant benefit while the storing of the built binaries brough instant liabilities. Git, unfortunately, has some fundamental issues when dealing with large binary files.

Where do you draw the lines at using VC in the right ways and when do you start investigating more appropriate solutions?

Answer 1

You probably shouldn't be storing the "entire virtualized build system" as a giant binary. If you want to version your application, you version the source code, not the compiled binary.

What many shops do is store in version control the steps to recreate the build server. Then you need one fixed image (a stock, out-of-the-box OS install), plus a small number of files (what to install on it, and how). Some places even have their server rebuild the app from source, on a clean OS install, for every deploy/reboot.

Versioning the OS image itself as a giant binary isn't nearly as useful. You can't branch. You can't merge. You can't diff. What's the point? You might save space if your VCS can do binary diffs, but that probably takes a ton of CPU and memory to do, and if they're on a "disk is cheap" binge, then there's no reason to make life painful just to save disk space.

Either store your install scripts/libraries in VC and rebuild the VM image as needed, or just store VM images in normal files. I don't see any point in putting the images in VCS.

Answer 2

I'd say there's an order of operations here:

If they need to store files, use a file system.

If they need to track changes, use version control.

If they need to track relationships to data, use a database.

The more complicated the requirements, the more complicated the solution. But discipline is in order for those who want the more complicated solution; in these uncertain times one must avoid wasting time.

Answer 3

What I always put in version control:

• source code and makefiles: the minimum needed for building binaries.
• tests suites

What I never put in version control:

• built binaries: they can be recreated from source control, and if I know that I may need a specific release immediately, I store them in file system in a way similar to Linux kernel.

What I put in version control depending on project:

• build chain: I don't put it in version control when I trust the provider or when I can recreate the environment (Apple's Xcode, open-source tools such as gcc or doxygen, ...). I put it in version control when it is specifically dedicated for the project (e.g., home made cross compilation chain) and when I need to recreate a binary exactly as it was built for delivery (for finding heisenbugs when any component may be involved, from the code to the OS or compiler).