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.
Also see Nathan's option-naming proposal at the end of this message.
>> Which WC format did our hypothetical user want? (Rhetorical.) The
>> current implementation gives them the highest format compatible with the
>> requested version. But contrast that to our planned behaviour of 1.15
>> which is to select the older format (31) by default. To me, that is
>> already showing the cracks in this approach.
>
> In the described scenario, the user wanted any format that 1.15 can
> write to. They don't care which one, and accordingly we can leave it
> unspecified (an implementation detail) which would be selected. This
> user doesn't constrain us.
>
> Another user may expect --bikeshed=1.15 to select the _newest_ format
> 1.15 can write to. This user is certain to exist; they're the reason
> we're writing this feature.
>
> Yet another user may expect --bikeshed=1.15 to select the _oldest_
> format 1.15 can write to, you say in your next paragraph. However,
> I don't see why any user would expect that. [...]
Yes, all fair. I think I now can accept that the current meaning
(highest format supported by the specified client version) is OK.
>> Consider [...] --wc-format=$(/opt/bar/bin/svn --version
>> --show-item=wc-format-default)»
>
> Clearer, yes, but does this serve a use-case? Is there a user who would
> expect this to be possible? As opposed to just "give me something 1.15
> can read and write"?
Maybe there is no need.
> 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.
>> Potentially the user can select from "-default", "-min", "-max" variants
>> of that option.
>
> KISS. [...]
Agreed; and I didn't mean we should expose that, just to use that idea
to help us think about the UI design.
> I suppose it's theoretically possible that there won't be a CLI
> incantation that will create f33; it will only be possible to create f32
> or f34. Is this a problem?
No problem. (If, say, a hypothetical 1.16 would add support for two new
formats (f33,f34), I can't imagine any reason why we'd ever do that and
also need to provide users the ability to specify the non-highest one
(f33 in this example) directly.
>> 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".
>> - rename the option to use a less ambiguous language, to something like
>> '--wc-format-version=1.8' (meaning the version in which this format was
>> introduced) or '--wc-format=31'
>
> Expecting a format number like this is basically asking the user to
> hardcode a magic number in their code, since there's no other way for
> them to learn the value "31".
OK.
[...]
>> > 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).
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.
> 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.)
- Julian
