git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joshua N Pritikin <jpritikin@pobox.com>
To: Yoshiki Ohshima <yoshiki@squeakland.org>
Cc: git@vger.kernel.org, sugar@laptop.org
Subject: Re: etoys - binary blob in GIT
Date: Fri, 9 Feb 2007 23:50:03 +0530	[thread overview]
Message-ID: <20070209182003.GE13381@always.joy.eth.net> (raw)
In-Reply-To: <u7ius5te9.wl%yoshiki@squeakland.org>

On Fri, Feb 09, 2007 at 04:41:34AM +0900, Yoshiki Ohshima wrote:
> > 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.

>   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.

>   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

       reply	other threads:[~2007-02-09 18:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070208095523.GE3708@always.joy.eth.net>
     [not found] ` <u7ius5te9.wl%yoshiki@squeakland.org>
2007-02-09 18:20   ` Joshua N Pritikin [this message]
2007-02-09 19:35     ` etoys - binary blob in GIT Yoshiki Ohshima
2007-02-10  9:49       ` Joshua N Pritikin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070209182003.GE13381@always.joy.eth.net \
    --to=jpritikin@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=sugar@laptop.org \
    --cc=yoshiki@squeakland.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).