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?)

[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
    x86-64.
[**] Here's a 64-bit byte swapper based on something I found buried in
     the apr source:
#if APR_IS_BIGENDIAN
#define UINT64_TO_FROM_BE(in,out) do { } while(0)
#else
#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 */