Pristines-on-demand=enabled == format 32?

[Johan Corveleyn <jc...@gmail.com>]

I think this was asked several times before, but I can't find the
thread: is the pristines-on-demand behavior still unconditionally tied
to format 32? Or is it that format 32 makes it _possible_ to enable
pristines-on-demand?

I would object to having pristines-on-demand=enabled coupled to simply
having WC format 32. Enabling pristines-on-demand should be optional.
Having the feature available as of format 32 sounds fine, but coupling
it unconditionally to format 32 sounds wrong. What if 1.16 introduces
format 33 with a nice new feature I want, but I want a pristine-full
working copy with it?

-- 
Johan

Re: Pristines-on-demand=enabled == format 32?

[Johan Corveleyn <jc...@gmail.com>]

On Thu, Apr 7, 2022 at 6:07 PM Julian Foad <ju...@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

Re: Pristines-on-demand=enabled == format 32?

[Julian Foad <ju...@apache.org>]

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.

Am I missing some other need? What seems to be the problem really?


> I tried to suggest a slightly more flexible per-WC-config [...]

I appreciate your suggestions. I think you are on the right track for
forward-thinking and architecturally sound design. It's something we can
take into account when naming the parts and designing the config options.

- Julian

Re: Pristines-on-demand=enabled == format 32?

[Johan Corveleyn <jc...@gmail.com>]

On Wed, Apr 6, 2022 at 4:28 PM Julian Foad <ju...@apache.org> wrote:
>
> Johan Corveleyn wrote:
> > I think this was asked several times before, but I can't find the
> > thread: is the pristines-on-demand behavior still unconditionally tied
> > to format 32? Or is it that format 32 makes it _possible_ to enable
> > pristines-on-demand?
>
> Currently it's tied to f32, but it's pretty clear it needs to be
> uncoupled. The issue is:
>
> https://subversion.apache.org/issue/4889 "Pristines-on-demand: per-WC config"
>
> In principle we could address this later, only when a further new
> version is released with a further new format and a further new feature
> that users need to have available without enabling pristines-on-demand;
> but it seems more responsible to uncouple it before we release it.
>
> I think that means #4889 is the other blocker issue. (Does anyone see
> any way around it?)

Ah, yes, I think that makes #4889 a blocker.

I tried to suggest a slightly more flexible per-WC-config than just a
yes/no flag, but rather an open-ended "pristine strategy" or "pristine
storage strategy" value (of which we would now introduces two options:
"full" and "on-demand" / "lazy" / whatever) [1] [2]. But maybe that's
overdesign without having an idea about what other "pristine storage
strategies" might require in additional config details.

[1] https://lists.apache.org/thread/h7xomovdclcm91vrskvj8kb0dbm1jng5
[2] https://lists.apache.org/thread/n3j50zv4sssqjcjfnz44ht5ho9p6db3f

-- 
Johan

Re: Pristines-on-demand=enabled == format 32?

[Julian Foad <ju...@apache.org>]

Johan Corveleyn wrote:
> I think this was asked several times before, but I can't find the
> thread: is the pristines-on-demand behavior still unconditionally tied
> to format 32? Or is it that format 32 makes it _possible_ to enable
> pristines-on-demand?

Currently it's tied to f32, but it's pretty clear it needs to be
uncoupled. The issue is:

https://subversion.apache.org/issue/4889 "Pristines-on-demand: per-WC config"

In principle we could address this later, only when a further new
version is released with a further new format and a further new feature
that users need to have available without enabling pristines-on-demand;
but it seems more responsible to uncouple it before we release it.

I think that means #4889 is the other blocker issue. (Does anyone see
any way around it?)

- Julian