On Thu, Mar 10, 2022 at 5:59 AM Julian Foad <jul...@foad.me.uk> wrote:
>
> Nathan Hartman wrote:
> > Suggestion: The user provides the earliest SVN version with which they
> > want compatibility, and SVN picks the latest WC format version that is
> > compatible with it. [...]
>
> And Daniel Sahlberg wrote:
> >> Regarding how to handle --wc-format-version=1.9, I'm leaning towards
> >> "use the newest format that was known by 1.9". That would enable a
> >> use case where I check the version of "the other svn client" (maybe
> >> an IDE integrated client), find that it is X.Y and then just use that
> >> version number instead of having to find out when the wc format of
> >> X.Y was actually introduced.
>
> Daniel and Nathan: That's what the current implementation does. It
> sounds rational by itself, but I pointed out some problems. That rule is
> not immediately obvious when, for example, a naïve user sees
> '--compatible-version=1.15' in a script. And (more so because) it is not
> consistent with the format that svn 1.15 chooses as its default format
> for creating working copies. By default it chooses 1.8 format (f31), not
> 1.15 format (f32). Your views on that would be good to hear.
I know the above is several days old but I am trying to keep up while
on the road for $dayjob...
I wonder if user confusion can be mitigated / consistency could be
improved by calling it '--min-compatible-client=1.15' rather than
'--compatible-version'? Bikeshedding a bit but the rationale is to
indicate to users that when this option is given, they will require at
minimum a 1.15 client to process this WC. When not specified
explicitly, SVN would pick '--min-compatible-client=1.8' by default.
An alternative, if the above is still problematic, might be to just
let users choose the format number directly and rely on help text and
documentation to show two key pieces of information about each format
number: (1) what feature(s) it introduces and (2) the oldest SVN
client version that recognizes that format.
e.g.,
|--------|--------------------|----------------------------|
| WC Fmt | Compatible Clients | Introduced Feature |
|--------|--------------------|----------------------------|
| *f31 | SVN 1.8 and up | Working Copy Records Moves |
| f32 | SVN 1.15 and up | Pristines On Demand |
| f33 | SVN 1.17 and up | Foo Bar Baz |
|--------|--------------------|----------------------------|
Then users can make an informed choice:
o If they have installations of various older clients and don't need
Pristines On Demand, they could stick with the default or specify
f31 explicitly.
o If they need Pristines On Demand and don't mind upgrading every
workstation, they could pick f32 by specifying it explicitly.
o If a future client drops support for, say, f31 and f32, attempts to
request those format numbers would error out gracefully.
The asterisk by f31 in the table above indicates that this is the
format created by default by the running client, unless otherwise
requested.
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.
Cheers,
Nathan
