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.
Received on 2019-12-09 14:59:11 CET