Hyrum K Wright wrote on Thu, Jun 30, 2011 at 16:33:16 -0500: > On Thu, Jun 30, 2011 at 3:27 PM, Peter Samuelson <pe...@p12n.org> wrote: > > > > [Ivan Zhakov] > >> It should be easy to implement editing revprops without using SQLite: > >> in case someone modify revprop non-packed revprop file is created, in > >> read operation non-packed revprop file should be considered as more > >> up-to-date. In next svnadmin pack operation these non-packed files > >> should be merged back to packed one. > > > > +1. This would basically mean there's only _one_ code path for writing > > revprops, yes? 'svnadmin pack' gets a little more complex, but the > > rest of libsvn_fs_fs gets simpler. > > > > Anyone have time to actually do this? Converting the packed format > > from sqlite to the same format used for packed revs would be a bonus. > > I like this idea, but it would seem to introduce an additional stat() > call* for every attempt to fetch a revprop, because you'd first have > to check the "old" location, and then the packed one.
I don't like the idea of writing revprops outside the DB and moving them back in. (I think I already said why elsethread?) But I do like the idea from IRC of doing away with revprop shards in f5 completely. Specifically: either ALL revprops will be in the DB, or *all* revprops will be in the potentially-sharded plain files as in f4. That does imply a single stat() for FS objects that were open whilst the transition (to DB) was done --- the same as the dance that's being done today for opening a revision file. (It might even be possible to support bidirectional transition --- DB<->shards and back --- but that can wait.) Unrelated question: how do we handle the case of a client, linked to libsvn_fs 1.6, that opens an svn_fs_t object and then, concurrently, someone runs 'svnadmin1.7 upgrade'? The FS object is now invalid (and must be closed), but would the old client detect that? For that matter, does our current code error out if db/format is bumped under its feet? And also, the same question for a client linked to libsvn_fs 1.7, that opened an f4 FSFS that had gotten upgraded whilst it was running. (I'll answer these myself later, right now I just want to document them before I forget them) > As far as I can > see, you'd have to do this in every case; in other words, there isn't > a single-stat() short cut for the common case of non-edited revprops. > > -Hyrum > > * - I don't know why we seem to have this obsession with stat() calls > around here, but it appears to have rubbed off on me.