| 1 |
On Mon, Dec 26, 2005 at 08:12:03PM -0500, Dan Meltzer wrote: |
| 2 |
> On 12/26/05, Lares Moreau <lares.moreau@×××××.com> wrote: |
| 3 |
> > On Tue, 2005-12-27 at 00:59 +0000, Ciaran McCreesh wrote: |
| 4 |
> > > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer |
| 5 |
> > > <genstef@g.o> wrote: |
| 6 |
> > > | That will increase the sync time for all of our users - can we please |
| 7 |
> > > | keep this info out of the sync-tree? |
| 8 |
> > > |
| 9 |
> > > Learn to use the rsync exclude list. |
| 10 |
> > > |
| 11 |
> > I think the point was that the 'average' user needs to pull it as well |
| 12 |
> > and has _no_ use for it. |
| 13 |
> > |
| 14 |
> > There are already complaints about syncs taking to long. |
| 15 |
> |
| 16 |
> The complaints was about the cache, not about the actual sync time |
| 17 |
|
| 18 |
Complaints about both actually- try sync'ing on a crap connection. |
| 19 |
Rsync doesn't scale well the larger the dataset gets (the fact it |
| 20 |
still performs well is a testament to it being mostly a damn fine |
| 21 |
tool). We've got at least a 2.4mB overhead just for doing |
| 22 |
filelist/chksum transfers; that's not getting into pulling the |
| 23 |
_actual_ updates. |
| 24 |
|
| 25 |
|
| 26 |
> This is what, maybe the equivilent of a new ebuild once, and a -rX any |
| 27 |
> time somethings changed? It won't effect much at all and end up being |
| 28 |
> a lot more helpful (and quickly implemented) than waiting around for |
| 29 |
> someone to write a web database and pushing that through. |
| 30 |
|
| 31 |
Quicker balanced against proper; debate right now is if it's the |
| 32 |
proper place to do this (thus address that concern) :) |
| 33 |
|
| 34 |
|
| 35 |
> We have metadata.xml's, why not use them? |
| 36 |
|
| 37 |
We have ebuilds, why don't we stick it there? Arguement doesn't work |
| 38 |
well there ;) |
| 39 |
|
| 40 |
(No I'm not advocating tagging this into ebuilds btw). |
| 41 |
~harring |
Archives