[Openmcl-devel] How about Git?

[mikel evins]

> On Nov 30, 2015, at 1:49 PM, Gail Zacharias <gz at clozure.com> wrote:
> 
> One approach I haven't seen discussed (so perhaps it has a fatal flaw I don't know about) is for distribution to be done via a tarball that consists of the binary distribution plus a skeleton version control tree - i.e. a source tree checked out the central repo, but with all the files deleted, so just the vcs meta-data. Installation consists of unpacking the tarball, and then (by hand or via a script) issuing the appropriate vcs command to fetch the latest sources, and finally rebuilding the images from source.  By including the vcs meta-data in the tarball, you eliminate the failure mode of users not knowing where to get the sources, or getting the wrong version of the sources (although it doesn't eliminate the problem of users getting just the sources and not knowing how to get the binaries, which also used to happen, but that's more manageable).

There are some other projects that do distribution this way, and it seems to work for them. At least some of them also include a shell script that invokes git to pull the latest changes from the remote repo, so installation consists of downloading and unpacking the tarball, then running the included update script.

There’s still the question of how to track the versions of the needed binaries. It’s not a great idea to store large binaries in git, especially if they change often. Git doesn’t know how to store deltas of binaries, so it stores full copies, and repos explode in size. Perhaps ironically, a common piece of advice about how to store versioned binaries is to use Subversion.