Daniel, Thank you for reviewing multi-wc-format.
I think it would be good for us to be able to refer to the issue tracker. I'll file a 'multi-wc-format' issue and we can add sub-issues for changes we need or want. https://subversion.apache.org/issue/4883 "multi-wc-format" Daniel Shahaf wrote: > 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 agree with all of that, and it seems like something we should do before releasing the feature. Filed, quoting your comments, as: https://subversion.apache.org/issue/4884 "multi-wc-format: user visibility of WC version" > 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"? [...] Yes. Done in r1898364. > 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. Given how Subversion has matured, and how we are aware of the difficulties that WC version upgrades cause for users of multiple clients, we are now deliberately choosing compatibility as the default, now that we have the ability to do so. > 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 [...]? Good idea. Filed as: https://subversion.apache.org/issue/4885 "multi-wc-format: WC upgraded and not-upgraded notifications" with a short reply. > 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. Done in r1898365. > 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. A good idea in principle. Ideally, we should probably keep a machine-readable list of all test parameters, along with which subset we recommend for different purposes such as pre-commit checks, backport proposal checks, release candidate checks. I do not see a good place to put this right now. The closest thing we have already might be 'subversion/tests/README' or 'tools/dev/unix-build' but neither of these enumerates the test parameters. > Sorry for not getting to this before the merge. That's no problem. - Julian
