On Wed, Jul 6, 2011 at 2:55 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On Wed, Jul 6, 2011 at 23:30, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
>> On Wed, Jul 6, 2011 at 11:47 AM, 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]
>>>
>>>
>>> Can we decide on what to do here?
>>>
>>> Thanks,
>>>
>>> Daniel
>>>
>>>
>>> ---------
>>>
>>> My opinion:
>>>
>>> * (1) is orthogonal to the others, but may be a good idea if we refactor
>>> the FS so shortly before the release
>>>
>>> * (2) simplifies things, doesn't solve the problems with having an
>>> SQLite db authoritative for parts of the FS storage
>>> (read: cp(1) unsafe)
>>>
>>> * (3) has my +1, assuming it's sufficiently performant and the concrete
>>> design is reasonable
>>>
>>> * (0) would mean that if we refactor revprop storage later, 1.8 servers
>>> will have to try and read revprops from *three* places; and lots of
>>> headache in the upgrade (and read-from-a-being-upgraded-FS) codepaths.
>>> So, if f5 should be improved, I'd rather do that /before/ it's
>>> released (and has to be indefinitely supported).
>>
>> After a bit of thinking and discussion, Daniel and I have come up with
>> what we think is an acceptable solution, and I'm posting it here for
>> validation. (Daniel, please correct me if I've gotten something
>> wrong.)
>>
>> Revision properties will *not* be packed in an sqlite database, but
>> will instead be packed in a single packfile, much like revision are to
>> today.
> Are you suggesting to create single packfile for whole repository or
> packfile for each shard? Per shard packfile looks more reasonable for
> me.
Packfile-per-shard.
>> The key difference is that instead of having a separate
>> manifest file, the manifest will be prepended to the packfile, meaning
>> the two can be atomically replaced in the case of a propedit.
>> This solution has at least of couple of advantages:
>> * No need to check a separate "edited" file before reading the packfile
>> * The repo maintains consistency in the case of a filesystem copy
>> (helpful for backups)
>>
>> Revprops wouldn't be packed until explicitly asked to do so by
>> 'svnadmin pack' which means the frequent post-commit revprop editing
>> wouldn't pose a performance problem. In addition, the revprop
>> packfile manifest information won't be cached, since the manifest may
>> change. We don't anticipate this to be a problem, since it only adds
>> an extra seek() to the revprop lookup process (rather than the open()
>> + seek() in the rev packing world).
>>
>> Comments?
>>
>
>
> --
> Ivan Zhakov
>
Received on 2011-07-06 22:02:10 CEST