From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1F06iz-0002z5-7X for garchives@archives.gentoo.org; Sat, 21 Jan 2006 00:35:25 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k0L0XZDE001872; Sat, 21 Jan 2006 00:33:35 GMT Received: from egr.msu.edu (jeeves.egr.msu.edu [35.9.37.127]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k0L0XYKx017870 for ; Sat, 21 Jan 2006 00:33:35 GMT Received: from [69.176.143.70] (69-176-143-70.dov.spartan-net.net [69.176.143.70]) (authenticated bits=0) by egr.msu.edu (8.13.4/8.13.4) with ESMTP id k0L0XXqV028336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Jan 2006 19:33:33 -0500 (EST) Message-ID: <43D18228.6070802@egr.msu.edu> Date: Fri, 20 Jan 2006 19:36:56 -0500 From: Alec Warner User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050806) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-performance@gentoo.org Reply-to: gentoo-performance@lists.gentoo.org MIME-Version: 1.0 To: gentoo-performance@lists.gentoo.org Subject: Re: [gentoo-performance] gentoo-performance (sync speedups) References: <20060120004058.99380.qmail@web54514.mail.yahoo.com> <43D04AE6.4090002@gmail.com> <43D04B45.3030409@services-4u.net> <43D04FE1.3080703@gmail.com> <43D06992.30906@netsyncro.com> <43D07346.2040407@lunatic.net.nz> <43D084C5.1020804@egr.msu.edu> <43D11457.5010705@gmail.com> In-Reply-To: <43D11457.5010705@gmail.com> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 51a0a397-4d55-48e7-a3a6-cd30a9fab9f1 X-Archives-Hash: fc88fd45a7eab9aa8d044a8398bba2d1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 lnxg33k wrote: > Thanks Alec Warner for the great explanation. It still seems like by not > having portions of the tree by using EXCLUDEFORM and deleting the local > dirs that you'd save some time in the --metadata part of sync as less > ebuilds are available to be checked. Is this simply a wrong misconception? The portion that "updates metadata cache" has nothing to do with what ebuilds are in the tree. It simply takes the server-side caches ( pregenerated ) and sync them into your local cache. You could RSYNC exclude the whole tree and this will still happen for every package, since the metadata is generated on the server ( and the server has the whole tree ). Now if you were to rsync exclude metadata/ you would reduce the - --metadata portion...because it wouldn't happen ;) - -Alec Warner (antarus) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ9GCJ2zglR5RwbyYAQLajw/+Mvfu9+0Sfo8nHo7gbNytHRNL1jVI61RD /EIiZZwV067X77IP72o0Y7SICRvnooEqtLvQW+rd2c/Kb6W4EtDga94X8EbOrHIm 0/IFqg7OqUa/psU6IkaPk959u7UJTnqlWmzluLbqRTx/X03lpjk6n+V4BOTRhcTA WHa80quSpd5EkfdFAJ1oWVMn9ck7xSTn3ulzmlznCkLdWK6iR+m+r+wAWMPlcRFG xE/Ik5uMVemlWuAElhMoB4xr/2hKfcsu/Egw9F+zVL5+3mGMyygHhELAvTVHU/C9 jLX3noNFC+xSOesmC0e+l88Uyz2AYPuhg8S+3qciC+4Ax2QkDhhRxwM7lLF6yPBx UpDNnTecT1iVuFUhHP08T2GPq8Nyvtzj4oqgjzKq1+l2RdehDM8j0KZrq5ZwDszb CdKakVUrVXmMOEp16E48k5/66sulgJ5fNdVubJYNdPwsY2dNJ5MC7wbxSwIT46TD 88tYAgco4cH9o4whwL2KZIjCQodKgvNwCnvW3qeXOdD/WqRSvuVbFIZh/+YZMHXi KVnWrePS2kwukMiL28oB9fwsJomQpwxCJlhZxuLto7kM1vBhlKLOeFfoZ8gm6mrF gBkDwiyV7aNHL4tFgAGtvDPReQhRS4DcN61EVEOYxMxQIKh1lDSFR1UW+j538S9c J/7XGJI9CxQ= =Qike -----END PGP SIGNATURE----- -- gentoo-performance@gentoo.org mailing list