[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 15 May 2012 01:05:51 +0200

On Mon, May 14, 2012 at 05:42:01PM -0400, Greg Stein wrote:
> On Mon, May 14, 2012 at 3:12 PM, <stsp_at_apache.org> wrote:
> > Author: stsp
> > Date: Mon May 14 19:12:13 2012
> > New Revision: 1338350
> >
> > URL: http://svn.apache.org/viewvc?rev=1338350&view=rev
> > Log:
> > Use svn_hash__make() instead of apr_hash_make() in select places to ensure
> > stable ordering of output. This commit makes the output of 'svn status'
> > and 'svn proplist' stable.
> I think you're solving this at the wrong level. Why should the
> functions below care about stable ordering? These are hash tables,
> which *by definition* are "unordered". With these changes, you're
> affecting *all* users rather than just the places that are important.
> If you want stable ordering, then at some higher level _where ordering
> matters_, get an array of sorted keys and walk the hash table that
> way.
> I'm somewhere between -0.5 and -1 on this commit. I feel pretty
> strongly that this is not a correct solution.
> Thanks,
> -g

Yes, it is more of UI level issue that does not belong into the
core libraries. It should be done by the UI.

But the UI gets one path per callback invocation.
So it cannot control the order itself without buffering everything.
That is not acceptable either.

I had a patch that used a sorted array of hash table keys (still in
libsvn_wc, not in 'svn') but Bert objected to that due to performance
concerns and suggested to use the newly added stable hash table instead.

The unordered output sucks. This commit was the result of a user
complaining about unordered output of 'svn status' after he upgraded
to ubuntu 12.04 which includes apr-1.4.6. Unordered output which used
to be ordered is perceived as a regression by our users. IMO we can't
just ignore this problem.

What would you suggest to do instead? I'm open to suggestions.
Received on 2012-05-15 01:06:31 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.