Julian Foad wrote on Thu, Mar 17, 2022 at 11:10:32 +0000:
> Daniel Shahaf wrote:
> > + The upgraded working copy will be compatible with Subversion 1.8 and
> > + newer (this default may change ...
>
> Sure, +1, a bit clearer.
>
Committed.
> Also see Nathan's option-naming proposal at the end of this message.
Ack. We can still rename the option, but I didn't want to block committing
the usage message patch on that.
> > Format numbers are sequential. When upgrading from f30 to f40, there's
> > no way to skip f35. If we wanted that, we'd need some sort of
> > capability-like mechanism. Is that perhaps what you have in mind? That
> > a user might want to upgrade to 1.16 but not enable pristines-on-demand?
> > If so, we'll need a way to enable/disable pristines-on-demand that isn't
> > "format >= 32", as discussed previously.
>
> I think we will need that, yes.
OK. This is already tracked as SVN-4889 and marked as a blocker of
SVN-525.
> >> My point is, using the running software version as a proxy for a WC
> >> format introduces this ambiguity: [...]
> >> This is why I think we should do at least one of:
> >>
> >> - require the exact first-introduced version (1.8 or 1.15)
> >
> > I still don't like the idea of requiring users to figure out somehow
> > they should pass 1.8 when they want compatibility with 1.9. That's
> > a problem we should solve for them.
>
> Maybe. I can see it both ways. Maybe best to allow the flexibility in
> input ("=1.9") and make clear in the feedback (both immediate response
> from the command, and "svn info" kind of feedback) that the format
> chosen is compatible with "1.8".
`svn info` already does that:
% svn info
⋮
Working Copy Compatible With Version: 1.8
Working Copy Format: 31
The command's output idea is tracked in SVN-4885.
> [...]
> >> > Why should we move any of that to include/private/? [except]
> >> > SVN_WC__SUPPORTED_VERSION and SVN_WC__VERSION [...]
> >>
> >> They are all a closely related family. The minimum format numbers for
> >> old (no longer supported) features don't need to be used outside
> >> libsvn_wc upgrade code, indeed. But the minimum format numbers for new
> >> features that are within the range of supported formats DO from now on
> >> need to be known by libsvn_client. A new one of them will be introduced
> >> with format 32:
> >>
> >> #define SVN_WC__PRISTINES_ON_DEMAND_VERSION 32
> >>
> >> We could split up the list... or keep it all together.
> >
> > If it needs to be known by libsvn_client, then it should be in
> > include/private/… unless there is some reason it should be public?
>
> Indeed. I think "include/private" is right for now. Clients linking to
> libsvn_client will also need to know something about formats... I'm not
> sure whether to make these WC APIs public right away, so that any client
> developers can get on with using them. If not, if we would be expected
> to add alternative ways to access the info through libsvn_client public
> APIs (that hide WC format number details and expose the info another way
> (equivalent to the --bikeshed=1.15 UI and/or feature flags).
I'm afraid I'm having a hard time following your train of thought here:
I'm not sure which of the svn_wc__*/SVN_WC__* APIs mentioned upthread
you think to make public, and what kind of alternative you mean.
The cmdline client wc format logic doesn't use any private APIs. The
public libsvn_client API doesn't use format numbers either, other than
in svn_client_get_wc_formats_supported() and
svn_client_wc_version_from_format().
What questions might a client API consumer want to ask, that can't be
answered in a straightforward manner by the existing public APIs?
In the context of this branch, I guess the questions are "What clients
can read <format>?" and "What's the minimum format that <version>
supports?". The former is answered by svn_client_wc_version_from_format().
The latter can be answered on <version> by calling
svn_client_get_wc_formats_supported(), but doesn't seem to be
straightforward to answer on newer minor versions. So, perhaps we should
teach svn_client_get_wc_formats_supported() to take an svn_version_t*
parameter and return the formats supported by that version. Is this
useful enough to be included in the first release?
> Nathan Hartman wrote:
> > I wonder if user confusion can be mitigated / consistency could be
> > improved by calling it '--min-compatible-client=1.15' rather than
> > '--compatible-version'?
>
> That sounds good to me. That's both more understandable (to novice
> users) and more explicit.
No opinion here.
Datapoint: --compatible-version is the name used by «svnadmin create».
> > I am less fond of this second idea than the first one above
> > ('--min-compatible-client=1.15') because this second idea exposes
> > implementation details (f31, f32...), but this might nevertheless be
> > simpler for users as it eliminates any possibility for ambiguity.
>
> Yes, that's the dilemma. Probably the ideal would be to use version
> numbers for the main client UI (as in your naming suggestion,
> '--min-compatible-client=1.15') and also let the client expose the
> format details in a way that users can find if they want to learn and
> clarify what specifying a version really means. (As the 'svn' client now
> does in its --version display.)
+1
Cheers,
Daniel
