On Thu, Apr 7, 2022 at 6:07 PM Julian Foad <julianf...@apache.org> wrote:
>
> Johan Corveleyn wrote:
> > Ah, yes, I think that makes #4889 a blocker.
>
> Well, I'm having a hard time deciding what exactly we need and why.
>
> I previously said "it's pretty clear it needs to be uncoupled" but
> actually just now I've dived into it for a couple of hours, coding and
> thinking, and it's not at all clear what this means.
>
> Is it mainly about UI level naming in "checkout" and "upgrade" -- in
> other words, that we would prefer the user to say
>
> "svn checkout --enable-POD525"
>
> instead of (or in addition to) "--compatible-version=1.15"? And we would
> not need to support the combination of "=1.15" without "--enable-POD525"
> (in other words the feature is still coupled to the format in the
> implementation), but require it to be specified explicitly and error out
> if it isn't, in order to set a precedent that that's the option you'll
> also be needing to use in future versions?
>
> ('POD525' used here as a place-holder for the feature name that is to be
> decided.)
>
> If it's that kind of UI-level naming issue, then we probably want to
> also put corresponding entry in "svn info" saying "POD525 enabled?
> yes/no". And anywhere else the idea is exposed in the UI, if anywhere.
>
> And/or, is it that we want to put internal APIs in place that let the
> higher level code layers ask "is POD525 enabled?" and not have to change
> those callers when 1.16/new-wc-format-33 comes around? But I don't see a
> strong need for that. We are not making a strong case for any of this to
> be exposed in public APIs at this time at all and the internal API calls
> can surely be updated as and when needed.
>
> And/or, is it that we really need users to be able to create a format-32
> (v=1.15) WC that doesn't have POD525 enabled? I am pretty sure that is
> not the case.
Sorry for the late reply, but mainly this, yes. Users will not expect
the latest wc format to "force" them into POD525-enabledness. I think
it would be a mistake to hard-couple format-32 to POD525-enabled. And
uncoupling it only when format-33 comes around with another shiny
feature would be highly confusing IMHO.
Upgrading to the latest format is a natural thing to do. People might
just expect it to fix security bugs, or to give them the latest and
greatest features. People won't expect a simple
TortoiseSVN-right-click->upgrade to completely re-arrange their
working copy into POD525-enabled state (which is an optional feature
that won't benefit every possible working copy). If this is coupled I
am willing to bet that TortoiseSVN will have to introduce a warning
popup for the "upgrade" action telling them about POD525, what it will
do to their pristine-store (trying to explain what it even is to most
users), how it might cripple their experience if they are on
high-latency network, etc etc ...
It's different for WC-features that are not optional and that are the
"way forward" for everyone (like WC-NG was ... there was no option).
But when the new format introduces a choice of WC-layout (both of
which are valid and supported into the future), the format upgrade
itself should not make that "new choice" automatically (possibly
causing huge pristine-store reshuffling right then and there), but
keep things the old way for backwards compatibility, IMHO.
So yes, I think format-32 and POD525 should be decoupled in the API
and in the UI, and stored somewhere in the WC storage (in wc.db, as
Evgeny already suggested elsewhere I think).
--
Johan
