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.
So it is still fairly manageable to get a good backup.
> 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).
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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-07-06 19:27:38 CEST