On Fri, Nov 8, 2019 at 4:48 AM Daniel Shahaf <d...@daniel.shahaf.name>
wrote:
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 misunderstood... sorry! More below...
>> 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"
> ]]]
You're right. That would be immensely irritating...
Is it possible that printing unmodified items in a changelist was a
deliberate design decision way back when the changelist features came
to light, and we simply forgot?
We could say that 'svn status' by default only prints files that are
"interesting" (for some definition of "interesting") and the virtue of
being associated to a changelist makes a file "interesting" whether
it's modified or not. ???
>> '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».
This is a completely different discussion but I think top-level
commands would be better reserved for: basic operations, namespaces
for other features, and shortcuts for power users.
Basic operations are things like checkout, add, delete, move, copy,
list, status, info, log, revert, update, commit, switch, merge,
resolve, etc.
Namespaces organize related non-basic operations together. For
example, instead of 5 commands for dealing with properties (propdel,
propedit, propget, proplist, propset), under such a system these would
be subcommands of a single {property,properties,prop,props} top-level
command:
$ svn properties list
$ svn prop ls
Shortcuts for power users would be kept as top-level commands so that
power users won't have to type too much:
$ svn pl
is the "power user" version of "svn properties list."
For backwards compatibility, we'd have to keep all of the top-level
long names that we already have, too.
Then, a revamped changelists feature could be completely managed as
subcommands of a single {changelist,changelists,cl} top-level
command to list, create, and delete changelists, and add / remove
items to changelists. The same would be true of all new features
that need a suite of their own commands...
Since we're on the subject of bikesheds ;-)
Nathan
