Nathan Hartman wrote on Fri, Nov 08, 2019 at 00:58:29 -0500:
> Daniel suggested to leave the behavior of 'svn status' as-is, unless
> 'svn status' is run with both -v and -q.
That's not what I suggested.
I suggested to modify the behaviour if -q is passed, *regardless* of whether -v
is passed or not. In the truth table diff I posted, _two_ rows were modified,
not just one.
> I'm not really sure how this morphed into a discussion about 'svn
> info', tab-delimited values, RFC822, XML, and feature branches,
It started with my parenthetical observation that «svn info»'s output is hard
to parse in a shell script because it's not line based. (Example: list all the
directories that are at a depth other than 'infinity'.)
[I solve this with «perl -nE 'BEGIN { $/ = "" }' -E '…'», but that's a mouthful
to type, and doesn't even have the output parsed to a hash. With JSON output
it'd be more elegant: «svn info --json | jq 'map(select(.depth) | .path)' | jq -r '.[]'».]
> but if I may back up for a moment and talk about changelists again...
Of course you may. The subject line was changed; the two discussions can
continue in parallel.
> I think this is a bug. 'svn status' does not print unmodified items in
> the "default" changelist, and that is as it should be. For
> consistency, unmodified items in an explicit changelist shouldn't be
> printed either.
What bothers me is the following use-case:
[[[
Monday% svn revert -q iota A/mu
Monday% svn cl foo iota A/mu
⋮
Friday% svn st -q
--- Changelist 'foo':
M iota
Friday% vi A/mu
Friday% svn commit -mm --cl foo
Sending iota
Sending A/mu
Transmitting file data ..done
Committing transaction...
Committed revision 2.
Friday% svn up -q
Friday% svn merge -c -2 A/mu
Friday% svn ci -m "Revert accidental commit"
]]]
That can't happen in 1.14 because 'st -q' would list A/mu, but it would be
possible under all of the proposals so far (including mine).
What happened in this example is that A/mu was in the 'foo' changelist, but
that wasn't shown in the output. Effectively, A/mu's being in a changelist was
hidden state, something svn knew about but the user had to remember. We
shouldn't have hidden states; the output should show all relevant information.
(Of course, the million dollar question is what information is relevant…)
I'm not sure what to do. The first ideas that come to mind are:
.
(1) keep the status quo
(2) only hide unmodified, changelisted files if -q is passed twice or more
(3) invent a new option flag for hiding unmodified, changelisted files
(4) declare this example a non-problem
.
but there's probably a better solution.
> In my mind, listing changelists (and which files are "in" them) should
> be a documented part of the changelist feature, not something achieved
> by a non-obvious invocation of 'svn status'.
>
> 'svn changelist --list' is not congruent to the way properties and
> shelves are listed; i.e., those have a separate top-level command like
> 'svn proplist'. So, perhaps 'svn changelists' (plural)? That lines up
> with 'svn x-shelves', but I don't like that it differs only by one
> letter from 'svn changelist'.
Bikeshed, but: «svn changelist-list».
That's analogous to both «proplist» and «x-shelf-list».
> Perhaps 'svn changelist' or 'svn changelists' with no additional parameters
> should print the changelists and their files instead of the current behavior
> which outputs E205001?
Hmm…
Cheers,
Daniel
Received on 2019-11-08 10:48:11 CET