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

Re: svn commit: r1640915 - in /subversion/trunk/subversion: include/svn_fs.h libsvn_fs_fs/fs_fs.c tests/libsvn_fs/fs-test.c

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Mon, 24 Nov 2014 17:39:00 +0300

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.

-- 
Ivan Zhakov
Received on 2014-11-24 15:40:33 CET

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.