[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 6 Jul 2011 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?

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. 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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-07-06 19:02:31 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.