From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10759 invoked from network); 12 Jun 2004 08:59:13 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 12 Jun 2004 08:59:13 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BZ4M4-0001pR-3E for arch-gentoo-portage-dev@lists.gentoo.org; Sat, 12 Jun 2004 08:59:12 +0000 Received: (qmail 30908 invoked by uid 89); 12 Jun 2004 08:59:10 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 30449 invoked from network); 12 Jun 2004 08:59:10 +0000 Message-ID: <40CAC668.6020100@wanadoo.fr> Date: Sat, 12 Jun 2004 11:01:28 +0200 From: =?ISO-8859-15?Q?Philippe_Lafoucri=E8re?= Reply-To: lafou@wanadoo.fr Organization: Zeni Corporation User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Nilsson Cc: gentoo-portage-dev@lists.gentoo.org References: <40CA20FD.8040907@wanadoo.fr> <1087001708.28752.28.camel@newkid.milsson.nu> In-Reply-To: <1087001708.28752.28.camel@newkid.milsson.nu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-portage-dev] portage doc & cache X-Archives-Salt: b30dd171-254d-40b2-a1e6-bf31a520cf69 X-Archives-Hash: 394cd486476d3f44d96e982463311279 > Mabey rfc2616 can be of some nice inspiration about caching. > As always, I refer to Roy T. Fielding's "Architectural Styles and > the Design of Network-based Software Architectures" as a must read. I'll take a look at this. As you guys, I don't have enough spare time :p > You have just described subversion... > Anyway you might want to experiment with cvsup vs. rsync. Freebsd is using cvsup. That's the reason for sure. > Do some experiments and benchmarking. What if only the cache was > downloaded at sync? Say you have a sql backend for portage, just sync > that and download the ebuilds on demand. That's the idea. If you look at debian package system (I know, it's far different, but ideas can be used on both projects), an update will only fetch the "cache", and then, package en demand (using apt-get install) > Personally I like crazy =) I think you should have a better > understanding of the current system before you criticise it though. Of course, I don't criticise anything, or anyone. I know the maxim "If you want it, do it" (Copyright Linus ;p ). I'll spend sometime if I can to help you guys. > rsync is a file transfer program for Unix systems. rsync uses the > "rsync algorithm" which provides a very fast method for bringing remote > files into sync. It does this by sending just the differences in the > files across the link, without requiring that both sets of files are > present at one of the ends of the link beforehand. > > rsync allready does it's best to only download new information. There are too many files to consider now in portage. At start, portage had just a few hundred of files, and rsync was doing its job quite well. Now portage has more than 80 000 files. Rsync has to consider all of them, and it's *REALLY* too long + painfull (my laptop is almost unusable during rsyncing). Sound like a "select * from table" on a test server with 15 test clients => will break in production environnement with thousands of clients. -- gentoo-portage-dev@gentoo.org mailing list