Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

[Bolstridge, Andrew]
> Ok, but a) why can't the list of unpacked revprop files be cached at
> startup and updated as revprops are edited.

Because there's more than one server process. I have a repository at
work that is accessed over file://, svn://, and https://. (Someone
used to use svn+ssh:// too, but I think I got him to switch to one of
the others.)

> If this is too much trouble, b) why not write a list of edited
> revprop files to a single file instead

_This_ could actually be useful for svnsync, particularly if it came
with timestamps. That's the great failing of svnsync: if it misses
just _one_ revprop change, it has no way of knowing unless you resync
_all_ revprops again. I don't think it'd be as useful for this
purpose, though. Opening, reading, and parsing this file isn't going
to be cheaper than a _single_ attempt to open a revprop file that does
not exist. You have to make sure the cache of revision numbers ends up
being used for a lot more than one revprop lookup. And, given the
multithreaded / multiprocess nature of our server instances, I wonder
if this would be true, in the common case.

Of course, the same can be said for the min-unpacked-revprop file
today.

> Or of course c) store the list of edited, unpacked revprops in a
> sqlite DB table.

I wonder if opening and reading a sqlite file is really any easier than
opening and reading a flat file. I.e., it almost collapses to b).

Also, any time you introduce another sqlite file, if you want to
preserve the 'rsync backup' ability, which is where this whole thread
started, you have to have a way to regenerate it from scratch.

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/