call for insight: revision control and binaries

Question

humans write source code

revision control is used to record changes in the source code

tools process source code and generate machine-readable stuff (exec, libs, GUI code, etc.)

every once in a while i would like to save a copy of the tools' output (e.g. save executable of beta-release for ARM). i can manually save the tools' output giving it a name which reflects the point in the revision control history (e.g. use tag name). this seems awkward and error-prone.

i would like your insight into 2 things:

1. what are the pros/cons of using revision control to store tool-generated output at specific positions in the revision history graph? what non-RCS tools do you use as an alternative?

2. in mercurial, git, what's the best way to include tool-generated output in specific revisions and not others

Answer 1

I believe that binaries should not be stored along with their source code in version control.

Disadvantages:

• it encourages bad build practices in large projects. The best practice is to fully automate your full build (not just source compilation, but also running automated tests, the packaging of documentation, generation of a setup etcetera). Committing binaries enables you to ignore that: "just manually do the build for the parts that have changed".
• slower updates and commits
• need to deal with conflicts on binary files each time you update after doing a build
• commits which change source code but not the corresponding binaries will cause confusion among developers. How do you detect that there is a mismatch?
• svn update will update the timestamp of your binaries, confusing your build tools which will erroneously think the binaries are newer than your source code changes.
• it uses more disk space in the repository. (This may be negligible depending on your project.)

In general, I think you should avoid committing anything that is generated automatically in a deterministic way from other versioned resources. No redundancy -> no opportunity for inconsistencies.

Instead, use a continuous integration server to automatically rebuild (and run the tests) on each commit. Let this build server publish the binaries somewhere (outside SVN) if necessary, like a shared folder on the network.

Answer 2

I would recommend not mixing binary files with DVCS in particular (such as git and Mercurial). The main reason being: any non-mergeable files are a problem for DVCS. DVCS fundamentally relies on high-quality merges of files for the concept of DVCS to work (see this discussion on binary files in git).

I agree that binary files are worth storing. But they should probably be stored in a different place from your source version control system. Perhaps a server with controlled write access. Perhaps a separate centralised VCS repository, such as Subversion, if you want to preserve all history.

To avoid such a separation being "awkward and error prone" as you say, try to automate it as much as possible. Make an automated build procedure that ensures the source is versioned/tagged, does a complete build, and puts the output (properly named, versioned, tagged, etc) into the designated store.