Re: Git Vs. Svn for a project which *must* distribute binaries too.
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Jun 4, 2007, 23:48 UTC
- Message-ID
- <Pine.LNX.4.64.0706041923580.22840@iabervon.org>
- In-Reply-To
- <5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com>
On Mon, 4 Jun 2007, Bryan Childs wrote:
Show 18 quoted lines
> On 6/4/07, Linus Torvalds < [send email to > torvalds@linux-foundation.org via gmail] > torvalds@linux-foundation.org> wrote: > > So I *hope* that you want to just have automated build machinery that > > builds the binaries to a *separate* location? You could use git to archive > > them, and you can obviously (and easily) name the resulting binary blobs > > by the versions in the source tree, but I'm just saying that trying to > > track the binaries from within the same git repository as the source code > > is less than optimal. > > Oh lord no - I never meant to imply that we'd be checking those > binaries in, I just meant to hi-light that we need a central > repository to build those binaries from - otherwise we'd end up with a > selection of binaries for our users to download which contain a bunch > of different features if they were built from a combination of > repositories. I know you think everyone else is a moron, but we're not > quite dumb enough to think maintaining binaries in a repository is a > good idea :)
Actually, I've been playing with using git's data-distribution mechanism to distribute generated binaries. You can do tags for arbitrary binary content (not in a tree or commit), and, if you have some way of finding the right tag name, you can fetch that and extract it.
I came up with this at my job when we were trying to decide what to do with firmware images that we'd shipped, so that we'd be able to examine them again even if we lose the compiler version we used at the time. We needed an immutable data store with a mapping of tags to objects, and I realized that we already had something with these exact characteristics.
-Daniel *This .sig left intentionally blank*