Mark Phippard wrote on Wed, Jul 06, 2011 at 13:27:05 -0400:
> On Wed, Jul 6, 2011 at 1:20 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> > Mark Phippard wrote on Wed, Jul 06, 2011 at 13:01:58 -0400:
> >> On Wed, Jul 6, 2011 at 12:47 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> >> > This thread is now the only non-FSFS release blocker (filed as #3944).
> >> > Last I checked there were at least three solutions suggested, but no
> >> > consensus on which solution to implement.
> >> >
> >> > Some suggestions were
> >> >
> >> >
> >> > 0. Leave things as they are
> >> >
> >> > 1. Allow packing revisions without packing revprops.
> >> > (revprops/ remains as in 1.6/f4)
> >> >
> >> > 2. Have all revprops in the DB all the time, never in plain files.
> >> >
> >> > 3. Swap the DB for some other "A thousand revision's revprops in one
> >> > file" solution. [several suggestions as to that file's format]
> >>
> >> Should there be a new discussion about what is wrong with option 0?
> >> My recollection of the thread is that there were no issues raised that
> >> really "stuck". Meaning there was speculation and concern that turned
> >> out to be fairly manageable and a non-issue. So what is wrong with
> >> the current design approach?
> >>
> >
> > What about your own answers to points (2) and (3)?
>
> Not sure the question. I think we answered Kevin's original concerns.
> Namely that:
>
> 1) This is an optional feature that does not come into play unless you
> pack the repository.
> 2) If you do pack the repository, the SQLite databases are only
> written to by someone that edits a revprop.
>
[ also by commits ]
> >> 3) As long as we had a good design, this would have been my
> >> preference.
> >
> > Okay. Hyrum and I raised a few designs late on Friday, but I don't
> > recall discussion on which one was better.
> >
> >> Mainly because I think adding SQLite adds some unknowns.
> >> However, given that rep sharing is there, I am not sure it matters at
> >> this point.
> >>
> >
> > rep-cache.db isn't authoritative; it is consulted while writing the rev
> > files but never afterwards. revprops.db is authoritative (removing it
> > is comparable to deleting a rev file).
>
> That is mainly only a backup question though. A single packed
> revision file would also be a critical file that has to be preserved.
> Given that the current packing design is relatively easy to backup, a
> new design would only be slightly better in this area and that it
> would be easier still.
>
> I am not against a new design that does not use SQLite. I am against
> expanding the SQLite usage. My main objection to a new design is that
> it feels too late. I do not want to wait for it to be agreed upon and
> coded.
>
I'm not worried that it would take too long to code.
I am, though, worried about introducing bugs.
Received on 2011-07-06 19:37:31 CEST