1. How can a user ask a working copy what range of minor versions it
supports? Cf. "Compatible With Version:" in `svnadmin info` output.
I see these:
% subversion/svn/svn info wc --show-item=wc-format
31
% subversion/svn/svn info wc --show-item=wc-format-min
31
% subversion/svn/svn info wc --show-item=wc-format-max
32
%
but:
- They emit format numbers rather than version numbers. It would be
more useful to emit version numbers, or at least to expose the
format-number-to-version-number mapping in the public API.
- They aren't documented in the release notes (only in the help output).
- wc-format-min and wc-format-max are not attributes of the working
copy but of the Subversion library doing the query. It's this way
even in the API (svn_wc_info_t::wc_format_min and
svn_wc_info_t::wc_format_max), but shouldn't we change this? "Do one
thing and do it well.". «svn info»'s one thing is to report properties
of the working copy. Information about the library's capabilities
clearly belongs in «svn --version --xml» ;-)
[«svn --version» does in fact print the library's supported version
number range already.]
2. The comment in trunk just above STMT_UPGRADE_TO_32 is just an
ellipsis. It should be fleshed out. Would it be correct to change it
to say "Format 32 is identical to format 31"?
(I realize this will change on the pristines-on-demand branch, but
understanding trunk shouldn't require knowledge of contemporary feature
branches. E.g., if someone bisects trunk a year from now and lands on
what's currently HEAD, they shouldn't be faced with an ellipsis for
a comment.)
3. «svn upgrade» of an f31 working copy does nothing and prints nothing.
I see this is deliberate behaviour (by the docstring of
SVN_WC__DEFAULT_VERSION).
3.1. Should «svn upgrade» upgrade to the newest supported format?
That's what «svnadmin upgrade» does and what «svn upgrade» has done to
date, so users may expect this.
3.2. Failing that, should «svn upgrade» print an info message to the
effect of "I upgraded your wc to f31 but I can also upgrade it to f32 if
you request that explicitly", so users don't mistakenly assume they're
running the latest-and-greatest wc format?
4. Since wc-queries-test.c special-cases STMT_UPGRADE_TO_32,
wc-metadata.sql should grow comments pointing to the places outside
wc-metadata.sql itself that need to be changed when a creating a new
format.
5. We should probably keep a list somewhere of what set of «make check
WC_FORMAT_VERSION=%s» values is needed in order to cover all
currently-supported codepaths.
Sorry for not getting to this before the merge.
Cheers,
Daniel
