<div dir="ltr"><div class="gmail_default" style="font-size:small">I’m wondering if this is really a problem. We update CCL binaries only a few times a year, to handle hard-to-bootstrap changes. That’s 50 megabytes times the number of platforms on GitHub, but it’s only 50 megabytes on a machine that runs only one platform. Is that a problem? I don’t think so. Others?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 13, 2017 at 9:24 PM, mikel evins <span dir="ltr"><<a href="mailto:mevins@me.com" target="_blank">mevins@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On Feb 13, 2017, at 7:57 PM, Bill St. Clair <<a href="mailto:wws@clozure.com">wws@clozure.com</a>> wrote:<br>
><br>
> On Mon, Feb 13, 2017 at 7:26 PM, R. Matthew Emerson <<a href="mailto:rme@acm.org">rme@acm.org</a>> wrote:<br>
><br>
> In the Subversion world, sure, we could tag an old release, and that would include suitable bootstrapping binaries and interface databases.<br>
><br>
> In the git world, a tag (as I understand it) is essentially a pointer to a particular commit.  It is still necessary to have suitable bootstrapping binaries that will work to compile the sources at that point in time.  As a concrete example of what I mean by this, note that a current development ccl (i.e., 1.12-dev) can't build a ccl from the 1.11 sources.<br>
><br>
> ​This suggests a solution to me.<br>
><br>
> CCL would have two GIT repositories:<br>
><br>
> 1) Source code, tagged with releases, branched with patches for particular releases. Move its tag when you add a bug-fix patch to a release.<br>
><br>
> 2) Binaries. Branched from the beginning with one branch per platform. Tagged to match the source tags, but with unique names for each branch:<br>
><br>
> 1) Tags: 1.9, 1.10, 1.11<br>
><br>
> 2) Branches: darwinx86, linuxarm, linuxppc, linuxx86, solarisx86, windows​<br>
><br>
> <branch>: <tag>…<br>
> darwinx86: 1.9-dx86, 1.10-dx86, 1.11-dx86<br>
> linuxarm: 1.9-armcl, 1.10-armcl, 1.11-armcl<br>
> linuxppc: 1.9-pp, 1.10-pp, 1.11-pp<br>
> linuxx86: 1.9-lx86, 1.10-lx86, 1.11-lx86<br>
> solarisx86: 1.9-sx86, 1.10-sx86, 1.11-sx86<br>
> windows: 1.9-wx86, 1.10-wx86, 1.11-wx86<br>
><br>
> This would allow you to put the two directories side-by-side, and, on the linux-like platforms, have symbolic links from the source directory reference the binaries in the binary directory:<br>
><br>
> ccl/<br>
>   trunk/    # Source for master branch<br>
>     lx86cl -> ../trunk-bin/lx86cl<br>
>     lx86cl.image -> ../trunk/bin/lx86cl.image<br>
>     lx86cl64 -> ../trunk-bin/lx86cl64<br>
>     lx86cl64.image -> ../trunk-bin/lx86cl64.image<br>
>   trunk-bin/    # Binaries for master branch<br>
>     lx86cl<br>
>     lx86cl.image<br>
>     lx86cl64<br>
>     lx86cl64.image<br>
><br>
> We could have a script to run in the source directory to create the symbolic links from <dir>/foo to ../<dir>-bin/foo<br>
><br>
> One remaining issue is what to do with the header directories. We could either just have everybody always download all of them with the source, or put them with the binaries and use symbolic links from the source directory to get to them in the binary directory.<br>
<br>
</div></div>The main problem with storing binaries in git repositories is that git's diff algorithm is designed for diffing text files. It doesn't get particularly good results in the general case on binary objects. The practical result is that, in effect, any time you change a binary object, no matter how small the change, git will store a whole new copy of the entire binary object.<br>
<br>
That means that repos containing binaries that change often will tend to grow in size very much faster than repos that contain only text.<br>
<br>
That isn't necessarily a big problem, as long as the stored binaries don't change very often. In fact, you should be able to do a little back-of-the-envelope arithmetic to determine how big a problem it would be to store CCL binaries in a git repo. Go over the release history for the past couple of years and count up the number of times each binary object has changed. For each binary object, multiply its size by the number of times it changed. Add all those together for a rough estimate of the total size of the repo.<br>
<br>
The common strategy for storing binaries for git repos is to store them in something other than git, and use a git extension that stores pointer files in the repo. The pointer files refer to the non-gt storage for the binary files, and enable git to fetch and store the appropriate binary objects during push and pull operations.<br>
<br>
Here's a recent discussion of the problem and the current crop of solutions:<br>
<br>
  <a href="https://github.com/openframeworks/openFrameworks/wiki/Moving-binaries-out-of-the-repo" rel="noreferrer" target="_blank">https://github.com/<wbr>openframeworks/openFrameworks/<wbr>wiki/Moving-binaries-out-of-<wbr>the-repo</a><br>
<br>
GitHub provides support for git-LFS.<br>
<br>
<br>
</blockquote></div><br></div>