Philip Martin wrote on Tue, Feb 21, 2012 at 13:13:48 +0000: > Daniel Shahaf <danie...@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.
Of course. For properties (both node properties and revision properties), the same approach I suggested to consistent-order dump dirent hashes would work for properties too. Are there any other barriers to reproducible dump files? (What is left -- the in-dump headrs? The svndiffs?) I think your apr_hash_make_custom() could be useful for svnrdump.
