[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn status should not show unmodified files in changelists

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 7 Nov 2019 11:13:09 +0000

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.
Received on 2019-11-07 12:13:28 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.