[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Bazaar 1.3 preview
From: |
Robert Collins |
Subject: |
Re: [Gnu-arch-users] Bazaar 1.3 preview |
Date: |
Sat, 02 Apr 2005 04:03:25 +1000 |
On Fri, 2005-04-01 at 11:06 -0500, Aaron Bentley wrote:
> >>2) The flat-revision subdirectory structure in ~/.arch-cache leads to
> >>huge directories, this is not scalable.
>
> The arch cache doesn't list directories, so the O(n^2) directory listing
> time on certain silly filesystems doesn't affect it. In what was is it
> not scalable?
directory traversal will incur this overhead though, and we do
traverse. I'm not sure that this is a problem for us though - even on
such bad filesystems, the kernel should cache the result after the first
read.
> >> Is not version/patchlevel
> >>structure more balanced
>
> For my money, it doesn't solve anything. There are archives with
> thousands of revisions per version, and archives with huge numbers of
> versions.
>
> And of course, it's no help at all for archives with one version.
>
> > and more consistent?
>
> The Cache was there first. Why should it be the one to change?
IMO it doesn't .. being a separate object, I don't see there being a
consistency argument at all.
> > * just grouping revisions by archives leads to too big
> > directories, that's not a good use filesystem storage.
>
> If you really want to solve the too-big directories issue, you'll need a
> more sophisicated approach than just splitting the revision name off the
> end.
Yah.
Rob
signature.asc
Description: This is a digitally signed message part