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

Re: do away with db/revprops/*/, and a question about 'upgrade' concurrency (was: Re: Does fsfs revprop packing no longer allow usage of traditional backup software?)

From: Peter Samuelson <peter_at_p12n.org>
Date: Fri, 1 Jul 2011 13:03:50 -0500

[Hyrum K Wright]
> My understanding would be that we'd pack revprops just like we pack
> revision (one single concat'd file per shard), and then store any
> edits in separate files. We'd then "repack" the edits into the pack
> files when an admin subsequently runs 'svnadmin pack'.
> Aside from the complexity of having to attempt to open the non-packed
> file everywhere before failing through to the common case, I really
> like this solution. (So much so that I may go implement it...)

At the risk of derailing this thread for about the third time ... if
you _do_ implement this, I suggest a simpler _and_ faster variation on
the 'manifest' file: instead of ASCII digits and \n characters, I
suggest 64-bit binary integers, stored in a defined endianness[*].
Easy to do, though you do need a 64-bit version of htonl()/ntohl().[**]

Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
[*] Which endian?  A bikeshed.  Big-endian is traditional for
    "portable" files and protocols, but the old big-endian server CPUs
    (Cray, S/390, SPARC, MIPS, PA-RISC) seem to have all given way to
[**] Here's a 64-bit byte swapper based on something I found buried in
     the apr source:
#define UINT64_TO_FROM_BE(in,out) do { } while(0)
#define UINT64_TO_FROM_BE(in,out) do { \
        apr_uint64_t tmp = (in); \
        tmp = ((tmp & APR_UINT64_C(0xff00ff00ff00ff00)) >> 8) | \
              ((tmp & APR_UINT64_C(0x00ff00ff00ff00ff)) << 8); \
        tmp = ((tmp & APR_UINT64_C(0xffff0000ffff0000)) >> 16) | \
              ((tmp & APR_UINT64_C(0x0000ffff0000ffff)) << 16); \
        (out) = (tmp >> 32) | (tmp << 32); \
} while(0)
#endif /* APR_IS_BIGENDIAN */
Received on 2011-07-01 20:04:28 CEST

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