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 <peter_at_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.
Received on 2011-07-01 15:06:45 CEST