Julian Foad wrote on Wed, Nov 06, 2019 at 10:36:10 +0000:
> Demo:
> [[[
> $ touch a b c d; svn add a b c d; svn ci -m ""; svn up
> ...
> $ echo hello > b
> $ echo hello > d
> $ svn cl foo c d
> A [foo] c
> A [foo] d
> $ svn status -v
>                  1        1 julianfoad   .
>                  1        1 julianfoad   a
> M                1        1 julianfoad   b
> --- Changelist 'foo':
>                  1        1 julianfoad   c
> M                1        1 julianfoad   d
> $ svn status
> M       b
> --- Changelist 'foo':
>         c
> M       d
> ]]]
> 
> File 'c' shows up in the plain 'svn status' even though it is unmodified.
> 
> I propose we should change this so unmodified files are not listed. It would
> look like this:
> 
> [[[
> $ svn status
> M       b
> --- Changelist 'foo':
> M       d
> ]]]
> 
> A changelist heading is printed only when a file in that changelist is
> listed, so there will be no heading if no files in the changelist are
> modified. It would look like this:
> 
> [[[
> $ svn revert b d
> Reverted 'b'
> Reverted 'd'
> $ svn status -v
>                  1        1 julianfoad   .
>                  1        1 julianfoad   a
>                  1        1 julianfoad   b
> --- Changelist 'foo':
>                  1        1 julianfoad   c
>                  1        1 julianfoad   d
> $ svn status
> ]]]
> 
> Thoughts?

Yes, several.

1. Are you proposing a change to the CLI or to the API?  I assume it's a
CLI-only change (so compatibility is a non-trivial issue).

2. As Nathan said, this can make it difficult to answer "Which unmodified files
are in a changelist?".  (Yes, it's still possible to answer this by parsing
the output of «svn info», but that's far from elegant, particularly since it's
not line-based.)

The root issue here is that "an unmodified file is in a changelist" is an
uncommittable-metadata-only change.  Additions to changelists are explicit user
actions, so I think it's fair to assume they're important and should be shown
by default (and compatibility suggests this too).  However, they aren't
committable, so how about if we made -q hide such files, like it hides
unversioned files?  That is:

        -v passed?      -q passed?      prints unmodified, changelist'd files?
        ==========      ==========      ======================================
                                        1.14    proposed 1.15
                                        ----    -------------
        no              no              yes     yes
        no              yes             yes     no
        yes             no              yes     yes
        yes             yes             yes     no(?)

I kept «svn st» unmodified for compatibility, and by extension «svn st -v» is
unmodified too.  (Presumably «svn st -v» should be a superset of the other
modes.)  I'm not sure about 'svn st -vq', but going by 'svn log -vq', I assume
it should hide unmodified, changelist'd files in the fashion you suggested.
(But then, there's «svn st -quv» to think of…)

Makes sense?  Would this be consistent with how we handle other status values
(unversioned, conflicted, etc)?

Cheers,

Daniel

P.S. Come to think of it, a tab-separated output mode for «svn info» might be
nice; that is, instead of this:
.
    % svn info README
    Path: README
    Name: README
    Working Copy Root Path: /home/daniel/src/svn/t1
    URL: https://svn.apache.org/repos/asf/subversion/trunk/README
    Relative URL: ^/subversion/trunk/README
    Repository Root: https://svn.apache.org/repos/asf
    Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
    Revision: 1869138
    Node Kind: file
    Schedule: normal
    Last Changed Author: luke1410
    Last Changed Rev: 1746277
    Last Changed Date: 2016-05-31 14:07:51 +0000 (Tue, 31 May 2016)
    Text Last Updated: 2019-09-23 18:43:22 +0000 (Mon, 23 Sep 2019)
    Checksum: 0b8d04c92f856c0d66248cdccf031fb6c0f6e05e
    Changelist: foo
.
we'd have this:
.
    % svn info --tsv README
    README      README  /home/daniel/src/svn/t1 …

This would be one line per file, so it would be easier to parse in a shell
script.

Reply via email to