[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 */
