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

RE: APR hash order

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 21 Feb 2012 14:32:55 +0100

> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: dinsdag 21 februari 2012 14:14
> To: Daniel Shahaf
> Cc: dev_at_subversion.apache.org
> Subject: Re: APR hash order
>
> Daniel Shahaf <danielsh_at_elego.de> writes:
>
> > Philip Martin wrote on Tue, Feb 21, 2012 at 12:32:43 +0000:
> >> The dumpfile order is more interesting. Although we don't specify the
> >> dumpfile order until now it has been repeatable, at least when using
the
> >> same executable/libraries. I can see that this repeatability is useful
> >> to an administrator. Rather than fixing the testsuite to ignore
> >> dumpfile order changes perhaps we should remove the random
> behaviour and
> >> continue to provide repeatable dumpfiles? This would involve using
> >> apr_hash_make_custom rather than apr_hash_make. I don't know
> whether
> >
> > Instead of apr_hash_make_custom(), couldn't we dump entries in
> directory
> > order instead? That makes the order a function of the repository mirror
> > dumped, rather than of the software version used.
> >
> > For FSFS dirs are stored in an svn_hash_write2() hash; for BDB they are
> > stored in a skel of node-rev skels; both of these structures are
> > naturally ordered, though in the former case we discard the order when
> > we parse the rep.
>
> That might be possible. There may be other hashes beyond the directory
> entries, I guess the properties associated with a node might be in hash
> order. Making the directory order repeatable only really makes sense if
> we end up with a dumpfile that is identical.

I don't think this will really help. Implementing EditorV2 will break these
same tests, and probably a lot more that have similar assumptions on other
orderings.

        Bert
Received on 2012-02-21 14:33:29 CET

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.