Evgeny Kotkov wrote on Thu, Aug 03, 2017 at 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.
We have a mix of options that depend on SVN_VER_MINOR and on
ffd->format.
SVN_VER_MINOR:
[memcached-servers]
[caches]
[debug]
ffd->format:
[rep-sharing]
[packed-revprops]
[io]
both:
[deltification] - requires ≥1.8 and ≥f4
> 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.)
The worst that can happen is:
1. Admin uses 1.9
2. Admin installs 1.10
3. Admin changes a fsfs.conf setting by hand
4. Admin serves the repository using 1.9
and at that point, some reps would be written with the wrong compression.
Note that lz4 has nothing to do with this question, since neither 1.9
nor 1.10 will write svndiff2 data to a repository that 1.9 can serve,
since such a repository is necessarily ≤f7. The only possibility of
confusion is if the admin sets 'compression' to one of 'none', 'zlib-1',
…, 'zlib-9' and then 1.9 will use another one of those ten.
As far as I can tell, that boils down to: if the admin changed the
defaults without RTFMing them, the admin will lose some performance.
I think the "1.10's UI shouldn't depend on the format number" point
below trumps this concern.
> 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 "downgrade" is "deinstall Subversion 1.10, install Subversion 1.9"
while keeping the repository at f7.
> 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.
>
Of course downgrading the libraries will bring changes. That's true
even if the UI doesn't change.
> > 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.
>
I don't understand what you mean by "explicit". I also don't understand
why it's an answer to "the way to disable compression in 1.10 is not the
same for all repositories, admins must learn two methods and remember to
check which one to use". This design would be a textbook example of the
reason dev@'s consensus generally frowns upon new knobs.
> > 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).
Yes, I think the way to disable compression in 1.10 shouldn't depend on the
format number.
Sorry for the late reply.
Cheers,
Daniel
Received on 2017-08-04 21:18:53 CEST