Markus Schaber wrote on Fri, Jul 01, 2011 at 08:51:43 +0200:
> Hi, Daniel,
>
> > Von: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
>
> > > 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. Daniel, is it makes sense for
> > > you?
> >
> > So you want the unpacked shard to be preferred to the packed one when
> both
> > exist.
> >
> > But when you have just finished packing a revprops shard, you have to
> > increment db/min_unpacked_revprop before deleting any revprop shards
> ---
> > and during that window, both the unpacked shard and the packed shard
> > exist, but you need to prefer the packed one.
>
> Why? For read access, both shards are supposed to have the same
> contents. And write access (revprop changes) could be blocked for that
> short window during a repo packing operation.
>
Commits, revprop changes, and packers all serialize on one lock.
And to answer your question: because if your supposed reader then makes
an edit, he'd be modifying the sharded file that the 'pack' process is
about to remove.
You could fix this particular race by having packers remove the sharded
files under the write lock, though. But in general I think I lean to
Peter's suggestion of just doing away with revprop shards in f5.
> Best regards
> Markus Schaber
Received on 2011-07-01 15:15:30 CEST