Daniel Shahaf wrote:
[... It currently shows] the BASE
revision of ./ — and I'd like to have an indication that the wc is
mixed-revision.
[...] fast. I assume that
solutions that read wc.db but don't look at the on-disk files at all
would be sufficiently performant.
Thus, `svnversion` sans text mods is actually a very good fit for my
use-case.
'svnversion' sans text mods shows:
* the overall max and min revisions (not the revision of './')
* whether any path is switched
* whether any path is partial (non-infinite depth)
The bit you said you want is the one bit telling whether it's
mixed-revision, indicated by the presence of a colon in the output.
It's not clear whether you are thinking some of the rest of that info
would be nice to have as well.
But we don't need to pin down exactly what you would want for this use
case, because if we're going to add a new feature or option it should be
generically useful for a variety of cases.
Calling it a "--no-stat" option, though you agreed to rename it, does
somewhat hinder thinking about it functionally.
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".
'info --x-viewspec' provides a superset of the information `svnversion
--no-stat` would provide, at comparable cost, [...] However, I'd have
to parse and condense the information myself [...]
I mentioned 'viewspec' to discuss the functionality at a high level, not
to suggest you should parse that existing command's output.
The 'svnversion' command is, to me, a historical anomaly. In a
hypothetical UI redesign, it would be an alias for, let's say,
$ svn status --summary \
--show-items=revision-range,switched,modified,partial
1777000:1802000SMP
The current 'svn info --x-viewspec' would be an alias for
$ svn status --viewspec
--show-items=revision,switched,partial
svn checkout https://...@1801500 .
svn update -r1801000 dir1
svn update -r1802000 dir1/dir2
Your desired use case might be achieved by
$ svn status --summary \
--show-items=is-mixed-revision
:
Those are just just examples off the top of my head of how a more
joined-up UI might look.
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.
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.
- Julian
