Re: etoys - binary blob in GIT

Re: etoys - binary blob in GIT

[Joshua N Pritikin]

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

Re: etoys - binary blob in GIT

[Yoshiki Ohshima]

  Joshua,

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

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

Re: etoys - binary blob in GIT

[Joshua N Pritikin]

On Sat, Feb 10, 2007 at 04:35:07AM +0900, Yoshiki Ohshima wrote:
> > >   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.