Mark Phippard wrote on Wed, Jul 06, 2011 at 13:27:05 -0400: > On Wed, Jul 6, 2011 at 1:20 PM, Daniel Shahaf <[email protected]> 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 <[email protected]> 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.
