Julian Foad wrote on Mon, Dec 09, 2019 at 11:14:02 +0000: > It seems to me what you really need is a way to request some specific bits > of info about the "base shape" of the WC. The motivation for requesting > something more specific than the current output of 'svnversion' is clearly > the slow scanning for modifications, and so of course eliminating that scan > is a way forwards, but the functional requirement is not "please don't > report whether files are modified". (Imagine we implement filesystem change > monitoring to detect modifications: then no stats are needed to report > modifications.) Nor is the requirement "please don't stat any files on > disk", but rather "please tell me just whether the tree is mixed-revision".
To be precise, it's "tell me *efficiently* whether the tree whether the tree is mixed-revision". > Specifically I am saying that if there is reason to enable the output of > 'svnversion' to be trimmed down to a subset of the info, then the user > should also be able to trim down the output of related commands such as > 'viewspec' and 'status' and 'diff' in the same way. The reasons the user > may wish to trim down the output are not just because of slow disk scanning > to generate the output, but also because the user wants to eliminate > unnecessary noise, in some cases lots of it, from their visual parsing. > Taken to the extreme, of course, this could mean implementing a complex > request specification language, and that may be beyond what we want to > implement and beyond what most users would want to learn. On the other > hand, that has been raised several times as a missing useful feature. > Generally that is useful thing to have in any complex software. > > I know I am taking your "simple" request and demanding instead a rather big > redesign. But adding little piecemeal additions to odd commands here and > there is something that it is now time to stop doing, even more than it > already was. > > I would not like to see us add another little knob of this sort to the > 'svnversion' command, at least not in the main Subversion series where we > are aiming to stabilize. I suppose something like «svnversion --show-items=…» could work, where the items could be, say, min_revision, max_revision, text-mods, prop-mods, tree-mods, shallow, switched. In my use-case I'd hard-code --show-items=min_revision,max_revision. (It's a script, so there's no point in having the output include things I don't parse; and I consume the two revision numbers too, not just the "are they equal?" bit.) However, I do not intend to redesign four subcommands for this (diff, status, viewspec, svnversion). It started as a quick patch that seemed to have the potential to be useful not just to me, but I don't need it badly enough to invest weeks into it. If anyone else wants to overhaul the cmdline getter functions, they're welcome to do that. For my use-case I already implemented a workaround using sqlite3 directly. It's not a stable API, but that's a trade-off I'm willing to make in the circumstances in question (I'm not building an airplane, and I don't mind my code dying with an assertion failure when wc format 32 comes along). So, as far as I'm concerned, the issue is resolved. > You could add it as an 'experimental' UI thing, I suppose, but even then I > would prefer to see the community express some commitment to developing it > into part of a more unified UX like the ideas I outlined above.