[MERGE] inode sorted stats in status

[Robert Collins]

On Mon, 2008-09-01 at 22:57 -0500, John Arbash Meinel wrote:

> My specific issue is about handling backwards compatibility, etc. Once things
> land in bzr.dev, we generally have a certain amount of overhead that makes it
> difficult to turn something that is sort-of what we want, into something that
> is exactly what we want.

I can make it bzrlib.osutils._read_dir trivially; that will remove that
concern I think. 

> One other thing that I will point out is that you now introduce 2 sorts,
> rather than just one. I don't know if O(one_directory) is ever going to show
> up I know we found sorted(revisions) to be a measurable issue when working on
> the btree code. (Would it be better to 'insort' instead of append and then
> sort? I don't really know. Probably not with a list, because of memory
> allocation issues.)

So, we have two sorts because we're statting in a different order than
walk_dirs is guaranteed to expose. We could
 - not do this
 - change walk_dirs to return in arbitrary order
 - make it optional

Also, I don't want everything in pyrex unless really needed; I'd rather
keep ok things in python, or get a _really_ clean pure C implementation
that can be tested and profiled independently.

> I *don't* think that the read_dir() function as you have defined it, is really
> the api we want exposed from pyrex => python in the long term. It could be a
> sufficient stepping stone that it is worth merging for now.

Unfortunately, my crystal ball is broken, and I'm not sure what we do
want. I also don't like keeping code that is useful outside of bzr.dev -
it makes for larger, harder reviews, and longer time-till-benefit for
our users. None of which are good things. Code is easier to change in
small steps.

I also have another branch, dealing with stat(), which has many
conflicts, and an outstanding diff of 146K lines (from bzr.dev) which
I'm trying to sort out. I don't want to cross the streams here; the pain
is already too high.

I really don't want to bundle up a bigger patch than is needed.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080902/8653a350/attachment.pgp