{"thread":{"id":"6754","subject":"Re: etoys - binary blob in GIT","startedAt":"2007-02-09T18:20:03Z","lastAt":"2007-02-10T09:49:34Z","messageCount":3,"participants":["Joshua N Pritikin","Yoshiki Ohshima"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"34070","messageId":"20070209182003.GE13381@always.joy.eth.net","threadId":"6754","inReplyTo":"u7ius5te9.wl%yoshiki@squeakland.org","subject":"Re: etoys - binary blob in GIT","fromName":"Joshua N Pritikin","fromEmail":"jpritikin@pobox.com","sentAt":"2007-02-09T18:20:03Z","receivedAt":"2007-02-09T18:20:03Z","isPatch":false,"sender":{"key":"jpritikin@pobox.com","avatar":"https://gravatar.com/avatar/3f2561fdd7efac4e127dc65ac7e06f044069c115dcc94d0ac540f4126d47759d?d=mp&s=160"},"body":"On Fri, Feb 09, 2007 at 04:41:34AM +0900, Yoshiki Ohshima wrote:\n> > I suggest starting a new GIT repository without the image. Those who are \n> > interested in history can create a graft to the old repository.\n> \n>   Then, from now on, we are going to manage the \"history\" of the image\n> in not-so-well-managed manner (i.e., just a bunch of hand-numbered\n> files in a directory).  Which is more or less ok, I think.\n\nYah, that's exactly what I suggest.\n\nYou might store the current image number in GIT if you want to keep \ntrack of which image goes with which commit.\n\n>   What the Etoys team actually uses for our own change management is\n> called \"update stream\" mechanism.  That is a sequence of small patches\n> in text.  These patches are kept on an FTP/HTTP or WebDAV/HTTP server,\n> and the developers submit the patches via FTP or WebDAV, and other\n> users and developers fetches them via WebDAV or HTTP into their EToys\n> image.  The image in the git repository is made in this way.  95% of\n> the case, it is enough to recreate a \"practically\" identical image by\n> merely fetching the patches.\n\n95%? Just curious, why not 100%?\n\n>   These small files are the result of \"real development work\" and\n> should probably be kept as the record.\n\nAgreed.\n\nI think the proper way to do that is to clean the upgrade directory \nafter each commit so that the upgrade directory only keeps patches for \nthe current changeset.  I'm going to CC the GIT mailing list just to \nmake sure since you could get stuck with this history for a long time.\n\n>   We are not keen on changing the \"fetch\" part of it, as it is so nice\n> to be able to download directly into the OLPC image.  That means\n> that it would be nice to have a directory on a server that looks like:\n> \n> http://squeakalpha.org/swupdates/external/updates/\n> \n> and available via HTTP.  To push a patch, one could imagine to use git\n> and then some server side process copy the file to the directory.\n\nIvan should be able to do that easily with an update-hook.\n\n-- \nMake April 15 just another day, visit http://fairtax.org\n"},{"id":"34073","messageId":"usldf3z10.wl%yoshiki@squeakland.org","threadId":"6754","inReplyTo":"20070209182003.GE13381@always.joy.eth.net","subject":"Re: etoys - binary blob in GIT","fromName":"Yoshiki Ohshima","fromEmail":"yoshiki@squeakland.org","sentAt":"2007-02-09T19:35:07Z","receivedAt":"2007-02-09T19:35:07Z","isPatch":false,"sender":{"key":"yoshiki@squeakland.org","avatar":null},"body":"  Joshua,\n\n> >   What the Etoys team actually uses for our own change management is\n> > called \"update stream\" mechanism.  That is a sequence of small patches\n> > in text.  These patches are kept on an FTP/HTTP or WebDAV/HTTP server,\n> > and the developers submit the patches via FTP or WebDAV, and other\n> > users and developers fetches them via WebDAV or HTTP into their EToys\n> > image.  The image in the git repository is made in this way.  95% of\n> > the case, it is enough to recreate a \"practically\" identical image by\n> > merely fetching the patches.\n> \n> 95%? Just curious, why not 100%?\n\n  5% is guesstimate (of course), but for stuff like changing the\nupdate stream mechanism itself or the \".changes file\" management,\nchanging the class hierachy around String, or the change that relying\non some external file such as fonts, are something I would do in more\ncontrolled ways.  (With more careful tweaking these things are usually\npossible with the update stream mechanism, but...)\n\n> >   These small files are the result of \"real development work\" and\n> > should probably be kept as the record.\n> \n> Agreed.\n> \n> I think the proper way to do that is to clean the upgrade directory \n> after each commit so that the upgrade directory only keeps patches for \n> the current changeset.\n\n  I'm not sure what is the upgrade directory, so not sure the upside\nof this is.  Can you elaborate?\n\n> I'm going to CC the GIT mailing list just to \n> make sure since you could get stuck with this history for a long\n> time.\n\n  Ah, ok.  Hi, Hamano-san^^;\n\n-- Yoshiki\n"},{"id":"34094","messageId":"20070210094934.GH13381@always.joy.eth.net","threadId":"6754","inReplyTo":"usldf3z10.wl%yoshiki@squeakland.org","subject":"Re: etoys - binary blob in GIT","fromName":"Joshua N Pritikin","fromEmail":"jpritikin@pobox.com","sentAt":"2007-02-10T09:49:34Z","receivedAt":"2007-02-10T09:49:34Z","isPatch":false,"sender":{"key":"jpritikin@pobox.com","avatar":"https://gravatar.com/avatar/3f2561fdd7efac4e127dc65ac7e06f044069c115dcc94d0ac540f4126d47759d?d=mp&s=160"},"body":"On Sat, Feb 10, 2007 at 04:35:07AM +0900, Yoshiki Ohshima wrote:\n> > >   What the Etoys team actually uses for our own change management is\n> > > called \"update stream\" mechanism.  That is a sequence of small patches\n> > > in text.  These patches are kept on an FTP/HTTP or WebDAV/HTTP server,\n> > > and the developers submit the patches via FTP or WebDAV, and other\n> > > users and developers fetches them via WebDAV or HTTP into their EToys\n> > > image.  The image in the git repository is made in this way.  95% of\n> > > the case, it is enough to recreate a \"practically\" identical image by\n> > > merely fetching the patches.\n> > \n> > I think the proper way to do that is to clean the upgrade directory \n> > after each commit so that the upgrade directory only keeps patches for \n> > the current changeset.\n> \n>   I'm not sure what is the upgrade directory, so not sure the upside\n> of this is.  Can you elaborate?\n\nSure, something like this:\n\n$ export IMAGE=$HOME/etoys.image\n$ cd etoys\n$ git init-db\n$ echo 1 > image-version\n$ git add image-version\n$ mkdir upgrade\n$ cd upgrade\n$ ls\npatch1\tpatch2\n\n# These patches are the \"update stream\" from the previous commit to the \n# current commit.\n\n$ cat patch1\ntouch $IMAGE\n$ cat patch2\necho abc >> $IMAGE\n$ cd ..\n$ git add patch1 patch2\n$ git commit -a\n\n# After every commit, you can remove the previous update stream.\n\n$ git rm upgrade/*\n\n# Here is the update stream for the next commit:\n\n$ echo 2 > image-version\n$ cat upgrade/patch1\necho def >> $IMAGE\n$ git add upgrade/patch1\n$ git commit -a\n$ git rm upgrade/*\n\n# Etc\n\nNow you have a history of the update stream and you know which image \nbelongs with which commit.\n"}]}