Re: Git Vs. Svn for a project which *must* distribute binaries too.
- From
Bryan Childs <godeater@gmail.com>
- Date
- Jun 4, 2007, 15:38 UTC
- Message-ID
- <5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com>
- In-Reply-To
- <alpine.LFD.0.98.0706040755560.23741@woody.linux-foundation.org>
On 6/4/07, Linus Torvalds < [send email to torvalds@linux-foundation.org via gmail] torvalds@linux-foundation.org> wrote:
Show 6 quoted lines
> 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 :)
Show 6 quoted lines
> In *practice*, I suspect that once you get used to the git model, you'd > actually end up with a hybrid scheme, where you might have a *smaller* > core group with commit access to the central repository (in git, it > wouldn't be "commit access", it would really be "ability to push", but > that's a technical difference rather than anything conceptually huge), and > members in that core group end up pulling from others.
This sounds like what we eventually came up with. I'm not sure how soon we'll make a switch to a git repository, but when we do, this seems to be the best model for the conversion in the short term, and perhaps in the long term too.
> .. and that's exactly how you'd do it with git too. You wouldn't have a > "commit trigger", but you'd have a "receive trigger", which triggers > whenever somebody pushes to the central repository.
Yes, after I'd sent my email this morning I found you could do pushes as well as pulls. That'll teach me to RTFM properly next time.
> - realize that the git model tends to encourage many small commits > (because you *can* make commits without impacting others), so when you > fix something, or add a new feature, with git, you can do it as many > small steps, and then only "push" when it's ready.
This is what I personally was trying to advocate in our discussion - but I'm not sure everyone quite understood it. Hopefully your explanation will do a better job :)
> IOW, if you encourage people to do small step-wise changes, you > probably don't even *want* a build for each commit, you really want a > build for the case where "my feature is now ready, I'll push". So you'd > effectively get one build not per commit, but per "publication point".
Absolutely.
> Linus
Thanks for your time (and everyone else who replied) - it's very much appreciated!
Bryan