Re: blobs (once more)

From: Miles Bader <miles@gnu.org>
Date: Apr 7, 2011, 05:20 UTC
Message-ID: <buo4o6abpsg.fsf@dhlpc061.dev.necel.com>
In-Reply-To: <BANLkTim3kg1ycGkgWsqaZiqMY9LTKV6DBw@mail.gmail.com>

Pau Garcia i Quiles <pgquiles@elpauer.org> writes:

Show 10 quoted lines

> The usual answer to the "I need to put binaries in the repository"
> question has been "no, you do not". Well, we do. We are in heavy
> development now, therefore today's version may depend on a certain
> version of a third-party shared library (DLL) which we only can get in
> binary form, and tomorrow's version may depend on the next version of
> that library, and you cannot mix today's source with yesterday's
> third-party DLL. I. e. to be able to use the code from 7 days ago at
> 11.07 AM you need "git checkout" to "return" our source AND the
> binaries we were using back then. This is something ClearCase manages
> satisfactorily.

If it were me, I'd just store the huge binaries in some sort of separate remote filesystem, and then store the remote-file-system _paths_ to them in git (in a simple text file).

Then either use the build system or some sort of git filter to make sure that the actual library was installed before building based on the path read from the file in git.

[This would be a pain as a _general_ solution (for git), because it involves coordination with a the remote file system, etc, but for an organization like yours setting up a system for a specific product, it should be fairly easy to set up and maintain -- and particularly so if the main use is to store 3rd party library releases, as they're typically not going to be something that anybody will want to checkin, but rather installed by a small set of people.]

-Miles

-- 
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.