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

Re: svn commit: r1803639 - in /subversion/trunk: build/run_tests.py subversion/libsvn_fs_fs/fs.h subversion/libsvn_fs_fs/fs_fs.c subversion/libsvn_fs_fs/transaction.c subversion/tests/cmdline/svntest/main.py win-tests.py

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Thu, 3 Aug 2017 14:34:21 +0300

Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:

> Hmm. My first instinct would be to make the availability of the
> 'compression' knob coupled, not with the format number but with
> SVN_VER_MINOR, so the rule would be "1.10 recognises the 'compression'
> knob if set; 1.9 ignores it".
>
> That _would_ cause the knob to be silently ignored on downgrades, but
> the failure mode wouldn't be too bad (some performance loss; that's
> expected when downgrading), and it would only affect people who edited
> fsfs.conf from the default.

At this point, I am not too sure about why would we want to have this
different behavior for 'compression'. We haven't been doing this for
other config options that are coupled with certain format numbers —
and I think there is a plenty of such options.

Also, that would mean we would be retroactively adding support for the
new option to formats that did not have it when they have been released.
I think that rather important property that we try to keep is that, when
working with older repository formats, new versions of Subversion write
the same data to the disk that would've been written by the old versions.
(Unless there's a complelling reason to change this, say, to fix a bug.)

Somewhat orthogonally:

What's a downgrade in this context? As far as I recall, we don't have an
official way to downgrade a repository, and if it's the "create new repository
with --compatible-version, dump/load and replace the fsfs.conf with the one
you had in the newer repository", then I would say that falls a bit out of
scope.

A lot of existing options, e.g. the whole [deltification] or [io] sections,
are only available starting from the specific formats, so it would probably
be unwise for such users to assume that everything is going to (magically ;-)
work as before.

> On the other hand, recognising the knob only in f8+ would require
> administrators to learn two different ways to do one thing: "In one kind
> of repositories, you disable compression by doing X, and in another kind
> of repositories, you disable compression by doing Y" (where the two
> kinds are "≥f8" and "≤f7"). This fails PEP 20.

I think that it's the price of introducing the new explicit option that is
now used in favor of the old one. But that has been sort of the point why
we implemented it — to be explicit about what get's written on the disk.

> All in all, I think I'm leaning towards making the knob conditional on
> SVN_VER_MINOR rather than ffd->format, but not strongly. Let's say I'm
> +0.5 to SVN_VER_MINOR.
>
> Supposing the knob is coupled with the format number, should we issue
> warnings about that? For example, a warning in 1.10 about 'compression'
> being set when opening a f7-or-older repository, or a warning when
> 'compression' is set and upgrading f7-or-older to f8-or-newer? These
> situations, too, would change the observed behaviour.

That could be a possible improvement, but, on the other hand, I don't think
we have been doing this for existing options that can only be used starting
from certain formats.

Do you think that something is clearly broken in its current state? Because
personally, I am quite happy with what we have now in trunk (assuming the
updated fsfs.conf docs).

Thanks,
Evgeny Kotkov
Received on 2017-08-03 13:34:55 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.