[MERGE] inode sorted stats in status

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

>> So in the end, I'd like to see a bigger improvement before we bring this in. I
>> think you are probably on the right track, but 2s out of 35s isn't really
>> worth it yet.
> 
> If the code is solid, this is something I feel safe bringing in in small
> steps; I'd rather not save up a 'big bang' patch unless there is doubt
> that the end result would be merged, or that a particular step is in a
> good direction. Your review didn't seem to indicate either thing.
> 
> -Rob
> 

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.

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.)

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.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIvLmzJdeBCYSNAAMRAk5RAJ0ce6rPnBiGpKa/gD5PU7ObpbOI1ACfZPIs
ZzO5NjdcnDtoN8IzH0dzXdI=
=rh2y
-----END PGP SIGNATURE-----