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