Re: APR hash order

On Tue, Feb 21, 2012 at 7:32 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----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.

This is probably true. I've already had to adjust some test
expectations for this reason.

In an ideal world, we could write dump file / diff / properties /
whatever parsers to convert the output into an abstract representation
which would then be compared, much like we already do for disk
contents and status output.

-Hyrum

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/