Mark Phippard wrote on Wed, Jul 06, 2011 at 13:01:58 -0400: > On Wed, Jul 6, 2011 at 12:47 PM, Daniel Shahaf <danie...@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)? I'm not married to changing the format. But if there are good reasons to do so --- whether they be "Easier for administrators" (Kevin's original point) or "Easier for extension" (a property of Peter's suggestion) --- now is the best time to do so, before we have to support it, forever, while never blocking concurrent readers. > My answers: > > 1) I always thought packing was pointless without packing revprops. > You get the biggest win from the revprops. > > 2) I think this would be a terrible idea. Hot backup becomes nearly > impossible. > > 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). Apples and oranges. > > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/
