From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yoshiki Ohshima Subject: Re: etoys - binary blob in GIT Date: Sat, 10 Feb 2007 04:35:07 +0900 Message-ID: References: <20070208095523.GE3708@always.joy.eth.net> <20070209182003.GE13381@always.joy.eth.net> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII To: sugar@laptop.org, git@vger.kernel.org X-From: sugar-bounces@laptop.org Fri Feb 09 20:36:29 2007 Return-path: Envelope-to: glls-sugar@m.gmane.org Received: from pedal.laptop.org ([18.85.2.148]) by lo.gmane.org with esmtp (Exim 4.50) id 1HFbXo-00072M-Sj for glls-sugar@m.gmane.org; Fri, 09 Feb 2007 20:36:29 +0100 Received: from pedal.laptop.org (localhost.localdomain [127.0.0.1]) by pedal.laptop.org (Postfix) with ESMTP id 66842EF8103; Fri, 9 Feb 2007 14:36:27 -0500 (EST) X-Original-To: sugar@laptop.org Delivered-To: sugar@laptop.org Received: from spam.laptop.org (spam.laptop.org [18.85.46.23]) by pedal.laptop.org (Postfix) with ESMTP id 89F06EF8103 for ; Fri, 9 Feb 2007 14:36:26 -0500 (EST) X-ASG-Debug-ID: 1171049784-386b00070000-3Xmyjt X-Barracuda-URL: http://18.85.46.23:8000/cgi-bin/mark.cgi X-Barracuda-Connect: pbsg500.nifty.com[202.248.238.70] X-Barracuda-Start-Time: 1171049784 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from pbsg500.nifty.com (pbsg500.nifty.com [202.248.238.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by spam.laptop.org (Spam Firewall) with ESMTP id B66D3DE8E for ; Fri, 9 Feb 2007 14:36:25 -0500 (EST) Received: from YOSHIKI-T4.mb.infoweb.ne.jp (squeakalpha.org [208.49.99.251])by pbsg500.nifty.com with ESMTP id l19Ja3ng008856; Sat, 10 Feb 2007 04:36:03 +0900 X-ASG-Orig-Subj: Re: [sugar] etoys - binary blob in GIT In-Reply-To: <20070209182003.GE13381@always.joy.eth.net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.1 (i386-mingw-nt5.1.2600) MULE/5.0 (SAKAKI) Meadow/2.00 (KIKYOU) X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at laptop.org X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.8215 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-BeenThere: sugar@laptop.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of OLPC design, desktop platform and user experience" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sugar-bounces@laptop.org Errors-To: sugar-bounces@laptop.org Archived-At: 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