Re: svn commit: r1640915 - in /subversion/trunk/subversion: include/svn_fs.h libsvn_fs_fs/fs_fs.c tests/libsvn_fs/fs-test.c
On 24 November 2014 at 16:53, Branko Čibej <brane_at_wandisco.com> wrote:
> On 24.11.2014 14:28, Ivan Zhakov wrote:
>> On 21 November 2014 at 19:34, Branko Čibej <brane_at_wandisco.com> wrote:
>>> On 21.11.2014 17:07, Ivan Zhakov wrote:
>>>> On 21 November 2014 17:15, Branko Čibej <brane_at_wandisco.com> wrote:
>>>>> On 21.11.2014 14:41, ivan_at_apache.org wrote:
>>>>> Why do you want to be able to turn off log addressing, when you can just
>>>>> not use FSFSv7 in the first place?
>>>> This is just a small addition to existing API like
>>>> SVN_FS_CONFIG_FSFS_SHARD_SIZE, SVN_FS_CONFIG_FSFS_BLOCK_READ,
>>>> SVN_FS_CONFIG_BDB_TXN_NOSYNC etc. It doesn't change user-visible
>>>> behavior and I'm planning to use this in the test suite.
>>>> If you have any concerns regarding this change, please let me know.
>>> The parameters you mention are all performance-related knobs, so not
>>> quite comparable to the change you made. Perhaps a better comparison is
>>> the FS layout option (sharded vs. non-sharded, packed vs. unpacked).
>> That's not quite true. This API option is similar to the following:
>> 1) create a FSFSv6 repository
>> 2) upgrade it to the FSFSv7 format.
> I was under the impression that, since r1637184, upgrading from v6 to v7
> without a dump/load cycle is no longer realistic for non-trivial (i.e.,
> non-empty) repositories?
The 'svnadmin upgrade' command always upgrades to the latest
repository format. It leaves marker in FORMAT file if some feature
cannot be enabled during in-place upgrade. That's why FORMAT file
still have option for non-sharded layout and physical addressing.
Received on 2014-11-24 15:40:33 CET
This is an archived mail posted to the Subversion Dev