From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j49Ao2a9018173 for ; Mon, 9 May 2005 10:50:02 GMT Received: from adsl-67-39-48-193.dsl.milwwi.ameritech.net ([67.39.48.193] helo=exodus) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1DV5pu-0006Y5-6r for gentoo-dev@lists.gentoo.org; Mon, 09 May 2005 10:50:06 +0000 Date: Mon, 9 May 2005 05:50:19 -0500 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: emerge-webrsync bandwidth improvement Message-ID: <20050509105019.GD26049@exodus.wit.org> References: <20050422130151.GB16038@exodus.wit.org> <4278BF96.2000909@b-i-t.de> <20050505030235.GA13705@exodus.wit.org> <427F0CC5.3010000@b-i-t.de> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427F0CC5.3010000@b-i-t.de> User-Agent: Mutt/1.5.8i X-Archives-Salt: 457c7421-8ff5-47bf-9bc7-e714d0fa026c X-Archives-Hash: 387f8ec83e8f92c0b38257c4c1a0e9a6 On Mon, May 09, 2005 at 09:09:57AM +0200, sf wrote: > Brian Harring wrote: > ... > > B) Permenant solution needed for when snapshots upstream aren't > > generated, as occured 04/29. This probably will have to be > > serverside- easiest route, otherwise have to implement version > > jumping logic in bash, which is ugly > > Generate an empty delta when no snapshot exists? Doesn't really work that way; each patch basically is a list of commands, multiple patches == pulling bits/pieces of commands from the the referencing version for that patch. Basically it's overlaying commands; an empty patch would break the chain. While it doesn't sound perfect/pretty, generating a patch that is just a copy of the reference (the command list is just a copy of all of the reference file to the versioned file). It's actually easier/cleaner to go this route, then modify the client- the client's approach is simply, I get patch from day N-1 to N, wash rinse repeat. Modifying it to handle arbitrary jumps basically means the client has to inspect the remote server for what's available, rather then just making an attempt for a fetch. It's easiest, and is only around 60 bytes per day upstream snapshots go out... so it's minor overhead, and shouldn't occur all that often :) > > C) cleansing of old snapshots. Current 'handling' of it (read: not > > doing a damn thing) is ugly. :) > > Always create the most recent snapshot and delete old snapshots and all > deltas? Pretty much. Pushed emerge-delta-webrsync-2 into the tree last friday, should address all of the issues I mentioned. ~brian -- gentoo-dev@gentoo.org mailing list