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
