threads / discuss / 6754

Re: etoys - binary blob in GIT

Subject: Re: etoys - binary blob in GIT

## tl;dr

3 messages between Feb 9, 2007 and Feb 10, 2007.

replies: 2people: 2as markdown or json

Joshua N Pritikin· Feb 9, 2007, 18:20 UTC · lore
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
Yoshiki Ohshima· Feb 9, 2007, 19:35 UTC · re: Joshua N Pritikin · lore
  Joshua,
Show 10 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%?
  5% is guesstimate (of course), but for stuff like changing the
update stream mechanism itself or the ".changes file" management,
changing the class hierachy around String, or the change that relying
on some external file such as fonts, are something I would do in more
controlled ways.  (With more careful tweaking these things are usually
possible with the update stream mechanism, but...)
Show 8 quoted lines
> >   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 not sure what is the upgrade directory, so not sure the upside
of this is.  Can you elaborate?
> 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.
  Ah, ok.  Hi, Hamano-san^^;
-- Yoshiki
Joshua N Pritikin· Feb 10, 2007, 09:49 UTC · re: Yoshiki Ohshima · lore
On Sat, Feb 10, 2007 at 04:35:07AM +0900, Yoshiki Ohshima wrote:
Show 15 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.
> > 
> > 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 not sure what is the upgrade directory, so not sure the upside
> of this is.  Can you elaborate?
Sure, something like this:

$ export IMAGE=$HOME/etoys.image $ cd etoys $ git init-db $ echo 1 > image-version $ git add image-version $ mkdir upgrade $ cd upgrade $ ls patch1 patch2

# These patches are the "update stream" from the previous commit to the # current commit.

$ cat patch1 touch $IMAGE $ cat patch2 echo abc >> $IMAGE $ cd .. $ git add patch1 patch2 $ git commit -a

# After every commit, you can remove the previous update stream.
$ git rm upgrade/*
# Here is the update stream for the next commit:

$ echo 2 > image-version $ cat upgrade/patch1 echo def >> $IMAGE $ git add upgrade/patch1 $ git commit -a $ git rm upgrade/*

# Etc

Now you have a history of the update stream and you know which image belongs with which commit.

← back to recent threads