Re: svn commit: r1338350 - in /subversion/trunk/subversion: libsvn_subr/io.c libsvn_subr/skel.c libsvn_wc/wc_db.c

On Tue, May 15, 2012 at 01:02:40PM +0200, Branko Čibej wrote:
> That doesn't really make much sense. Only the test suite is intersted in
> /stable/ key ordering, and that's just because the test result
> comparison functions require it.

I don't think they do at present because the test suite would be
failing left and right if they did. Looking at the code, we build
a tree from status output and then compare this tree to an expected
tree. It looks as if the order of paths in status output is irrelevant.

> Users will not care about stable output unless it's sorted.

Sure. All I'm saying is that if the stable ordering happens to be
sorted, we're saving a qsort(). I don't care about an extra qsort()
myself. But Bert apparently does, and I'm trying to reach consensus.
 
> On the subject of hash functions, I doubt you can go much faster than
> what APR already has, except for saving the few bytes of the randomizer
> added to the key.

I didn't actually mean to make the claim that it was faster. I just
blindly believe the docstring of svn_hash__make() which claims this.
Received on 2012-05-15 13:19:37 CEST