[ Aside: in each of your paragraphs, every line other than the first starts with a U+200B ZERO WIDTH SPACE. While replying $EDITOR renders those as «<200b>» (six characters, and six terminal columns) by default. ]
Julian Foad wrote on Thu, Feb 24, 2022 at 13:59:08 +0000: > 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. +1 > Filed, quoting your comments, as: > > https://subversion.apache.org/issue/4884 "multi-wc-format: user > visibility of WC version" > Thanks. I'll follow up there. > > 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. > OK. However, in this case we should document this explicitly, since the book explicitly documents that «svn upgrade» would upgrade to the "most recent metadata format supported by your version of Subversion" (https://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.upgrade.html). I've grepped the book for «upgrade<» and I believe the only other place there we need to update is https://svnbook.red-bean.com/nightly/en/svn.ref.svnadmin.c.upgrade.html, to highlight the distinction. A release notes entry would be higher priority than updating the book. > > 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. > I'll follow up there. > > 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. We also have notes/knobs. tools/dev/unix-build isn't the right place, I think, since these settings aren't specific to Unix, and in any case, someone looking for that information wouldn't look for it under tools/. subversion/tests/README documents the test infrastructure. I think that's "developer documentation" of the test suite, whereas what we mean here is "user documentation" of the test suite, and would also discuss knobs only honoured by the C code (e.g., -DPACK_AFTER_EVERY_COMMIT, which causes some false positive FAILs). So, let's just add a new wiki page, or a text file in notes/? Whatever is least overhead. I'll follow up on the new issues separately. I'll also label "api" those issues that require API changes and milestone "1.15.0" any blockers. Cheers, Daniel
