Re: blobs (once more)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Pau Garcia i Quiles <pgquiles@xxxxxxxxxxx> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]