Re: etoys - binary blob in GIT
- From
Joshua N Pritikin <jpritikin@pobox.com>
- Date
- Feb 9, 2007, 18:20 UTC
- Message-ID
- <20070209182003.GE13381@always.joy.eth.net>
- In-Reply-To
- <u7ius5te9.wl%yoshiki@squeakland.org>
On Fri, Feb 09, 2007 at 04:41:34AM +0900, Yoshiki Ohshima wrote:
Show 6 quoted lines
> > I suggest starting a new GIT repository without the image. Those who are > > interested in history can create a graft to the old repository. > > Then, from now on, we are going to manage the "history" of the image > in not-so-well-managed manner (i.e., just a bunch of hand-numbered > files in a directory). Which is more or less ok, I think.
Yah, that's exactly what I suggest.
You might store the current image number in GIT if you want to keep track of which image goes with which commit.
Show 8 quoted lines
> What the Etoys team actually uses for our own change management is > called "update stream" mechanism. That is a sequence of small patches > in text. These patches are kept on an FTP/HTTP or WebDAV/HTTP server, > and the developers submit the patches via FTP or WebDAV, and other > users and developers fetches them via WebDAV or HTTP into their EToys > image. The image in the git repository is made in this way. 95% of > the case, it is enough to recreate a "practically" identical image by > merely fetching the patches.
95%? Just curious, why not 100%?
> These small files are the result of "real development work" and > should probably be kept as the record.
Agreed.
I think the proper way to do that is to clean the upgrade directory after each commit so that the upgrade directory only keeps patches for the current changeset. I'm going to CC the GIT mailing list just to make sure since you could get stuck with this history for a long time.
Show 8 quoted lines
> We are not keen on changing the "fetch" part of it, as it is so nice > to be able to download directly into the OLPC image. That means > that it would be nice to have a directory on a server that looks like: > > http://squeakalpha.org/swupdates/external/updates/ > > and available via HTTP. To push a patch, one could imagine to use git > and then some server side process copy the file to the directory.
Ivan should be able to do that easily with an update-hook.
-- Make April 15 just another day, visit http://fairtax.org