Re: Pristines-on-demand=enabled == format 32?
On Thu, Apr 7, 2022 at 6:07 PM Julian Foad 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?
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?
On Wed, Apr 6, 2022 at 4:28 PM Julian Foad 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?
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
Pristines-on-demand=enabled == format 32?
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