Re: truncated author names in 'svn ls -v' output

[Vincent Lefevre]

On 2018-12-07 15:10:39 +0100, Branko Čibej wrote:
> >> Did you have some specific change you wanted to propose?  (Other than
> >> making the 'author' column's width configurable)
> > I just wanted to have more than 8 characters for the authors names
> > (without changing the "file size" column).
> 
> Yes, the default width is still 8 columns but that will expand to up to
> 16 as needed, without any additional options.

OK, fine. Thanks for the information.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 07.12.2018 14:58, Vincent Lefevre wrote:
> On 2018-12-07 12:06:08 +, Daniel Shahaf wrote:
>> Vincent Lefevre wrote on Fri, Dec 07, 2018 at 12:43:42 +0100:
>>> the issue with the suffix solution (B/K/M/G) is that it is actually
>>> less readable when one has many files in the list. I mean that with
>>> the full file size displayed, it is very easy to see which files take
>>> the most space, or similar information: the number of digits gives the
>>> order of magnitude of the file size; this can be found in a fraction
>>> of second. With the suffix form, one needs to look at all the sizes
>>> one by one.
>> The output with SI suffixes is not the default.  If you don't opt-in to
>> it by passing a new-in-1.12 option, you will never see it in the first
>> place.
> I'm a bit lost. :( I thought that this was the solution to make
> more space for the author names (as the SI suffixes were discussed
> under this thread).

Note that with what's on trunk now, the author column will adjust its
width within limits anyway.

>> Did you have some specific change you wanted to propose?  (Other than
>> making the 'author' column's width configurable)
> I just wanted to have more than 8 characters for the authors names
> (without changing the "file size" column).

Yes, the default width is still 8 columns but that will expand to up to
16 as needed, without any additional options.

-- Brane

Re: truncated author names in 'svn ls -v' output

[Vincent Lefevre]

On 2018-12-07 12:06:08 +, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Fri, Dec 07, 2018 at 12:43:42 +0100:
> > the issue with the suffix solution (B/K/M/G) is that it is actually
> > less readable when one has many files in the list. I mean that with
> > the full file size displayed, it is very easy to see which files take
> > the most space, or similar information: the number of digits gives the
> > order of magnitude of the file size; this can be found in a fraction
> > of second. With the suffix form, one needs to look at all the sizes
> > one by one.
> 
> The output with SI suffixes is not the default.  If you don't opt-in to
> it by passing a new-in-1.12 option, you will never see it in the first
> place.

I'm a bit lost. :( I thought that this was the solution to make
more space for the author names (as the SI suffixes were discussed
under this thread).

> Did you have some specific change you wanted to propose?  (Other than
> making the 'author' column's width configurable)

I just wanted to have more than 8 characters for the authors names
(without changing the "file size" column).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: truncated author names in 'svn ls -v' output

[Daniel Shahaf]

Vincent Lefevre wrote on Fri, Dec 07, 2018 at 12:43:42 +0100:
> the issue with the suffix solution (B/K/M/G) is that it is actually
> less readable when one has many files in the list. I mean that with
> the full file size displayed, it is very easy to see which files take
> the most space, or similar information: the number of digits gives the
> order of magnitude of the file size; this can be found in a fraction
> of second. With the suffix form, one needs to look at all the sizes
> one by one.

The output with SI suffixes is not the default.  If you don't opt-in to
it by passing a new-in-1.12 option, you will never see it in the first
place.

Did you have some specific change you wanted to propose?  (Other than
making the 'author' column's width configurable)

Re: truncated author names in 'svn ls -v' output

[Vincent Lefevre]

On 2018-11-26 18:19:59 +0100, Stefan Sperling wrote:
> On Mon, Nov 26, 2018 at 04:30:27PM +0100, Vincent Lefevre wrote:
> > On 2018-11-26 15:18:47 +0100, Branko Čibej wrote:
> > > Do please read the rest of the thread. A solution has already been
> > > implemented on trunk.
> > 
> > Except that this solution is not satisfactory for me. I guess that
> > the ultimate solution is to use --xml + a wrapper (thus one could
> > add things like coloring), though that's still limited as one
> > doesn't get the MIME type (svn:mime-type).
> 
> Please don't poke our grumpy Brane bear; we need him to stay in a good mood.
> You see, if you don't like Brane's solution, and you already have a
> working alternative of your own invention which you prefer anyway, then
> pointing out that Brane's solution is unsatisfactory to you just comes
> across as... kind of rude. Even if not meant that way, this was certainly
> not a constructive comment to make on a mailing list such as this one.

Well, if you want a constructive comment, the issue with the suffix
solution (B/K/M/G) is that it is actually less readable when one has
many files in the list. I mean that with the full file size displayed,
it is very easy to see which files take the most space, or similar
information: the number of digits gives the order of magnitude of the
file size; this can be found in a fraction of second. With the suffix
form, one needs to look at all the sizes one by one.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 28.11.2018 16:10, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, Nov 27, 2018 at 14:49:59 +0100:
>> On second thought, I think I should revert this. Consider the
>> inconsistency with --show-item=last-changed-date:
>>
>> $ svn info ^/subversion/trunk/CHANGES --human-readable 
>> --show-item=last-changed-date
>> 2018-11-26T02:50:47.513639Z
>>
>> but
>>
>> $ svn info ^/subversion/trunk/CHANGES | grep '^Last Changed Date'
>> Last Changed Date: 2018-11-26 03:50:47 +0100 (Mon, 26 Nov 2018)
>>
>>
>> The output from --show-item was always meant to be strictly for scripts.
> That's an interesting one.  I never realized that --show-item formats
> the output differently; I assumed it was designed to simply save scripts
> having to do the
> .
> LC_ALL=C svn info "$@" | sed -ne 's/^Last Changed Date: //p'
> .
> dance, without requiring any other changes on scripts' side.
>
> So on the one hand, I understand your argument: proliferation of output
> formats is bad, and we don't want to have four or five different date
> formats ('svn info', 'svn info --show-item', 'svn info --xml', and
> '--human-readable' versions of the first two).
>
> On the other hand, I don't quite understand your argument: I don't
> understand why "The output from --show-item was always meant to be
> strictly for scripts" is an argument against "'svn info --show-item'
> should format the output differently if a new opt-in option flag,
> --human-readable, is passed".  Adding that flag is fully backwards
> compatible with existing scripts that use --show-item.  In your example,
> «svn info --show-item=last-changed-date» could continue to emit the raw
> ISO8601 form, as it does now, and if --human-readable is passed it could
> emit some other format.
>
> All that said, if you feel it's better to remove -H from 'info' for now,
> then sure.  We can always add it in a later release.

I wasn't thinking about removing -H from 'info' but about removing it
from '-H --show-item=*'. Though of course you're right ... there's no
incompatibility.

/me thinks some more

-- Brane

Re: truncated author names in 'svn ls -v' output

[Daniel Shahaf]

Branko Čibej wrote on Tue, Nov 27, 2018 at 14:49:59 +0100:
> On second thought, I think I should revert this. Consider the
> inconsistency with --show-item=last-changed-date:
> 
> $ svn info ^/subversion/trunk/CHANGES --human-readable 
> --show-item=last-changed-date
> 2018-11-26T02:50:47.513639Z
> 
> but
> 
> $ svn info ^/subversion/trunk/CHANGES | grep '^Last Changed Date'
> Last Changed Date: 2018-11-26 03:50:47 +0100 (Mon, 26 Nov 2018)
> 
> 
> The output from --show-item was always meant to be strictly for scripts.

That's an interesting one.  I never realized that --show-item formats
the output differently; I assumed it was designed to simply save scripts
having to do the
.
LC_ALL=C svn info "$@" | sed -ne 's/^Last Changed Date: //p'
.
dance, without requiring any other changes on scripts' side.

So on the one hand, I understand your argument: proliferation of output
formats is bad, and we don't want to have four or five different date
formats ('svn info', 'svn info --show-item', 'svn info --xml', and
'--human-readable' versions of the first two).

On the other hand, I don't quite understand your argument: I don't
understand why "The output from --show-item was always meant to be
strictly for scripts" is an argument against "'svn info --show-item'
should format the output differently if a new opt-in option flag,
--human-readable, is passed".  Adding that flag is fully backwards
compatible with existing scripts that use --show-item.  In your example,
«svn info --show-item=last-changed-date» could continue to emit the raw
ISO8601 form, as it does now, and if --human-readable is passed it could
emit some other format.

All that said, if you feel it's better to remove -H from 'info' for now,
then sure.  We can always add it in a later release.

Cheers,

Daniel

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 27.11.2018 12:22, Branko Čibej wrote:
> On 26.11.2018 04:15, Daniel Shahaf wrote:
>> Branko Čibej wrote on Sun, 25 Nov 2018 23:28 +0100:
>>> On 25.11.2018 18:42, Branko Čibej wrote:
 On 25.11.2018 11:58, Daniel Shahaf wrote:
> Branko Čibej wrote on Sun, 25 Nov 2018 06:06 +0100:
>> $ svn ls --verbose --human-readable
>> 1847281 stsp  Nov 23 16:04 ./
>> 1716820 rhuijben 175B Nov 27  2015 .editorconfig
> 'svn info' doesn't print file sizes at all.  If it did, it could take
> the new flag too.
 svn info -H --show-item=size? :)
>>> But seriouisly '--human-readable' and '--show-item' would be incompatible.
>> I don't see why.  It would make perfect sense to have:
>> .
>> % svn info --human-readable --show-item=repos-size
>> 42KiB
>> % 
>> .
>> for interactive usage.
>
> This?
>
>
> $ svn info -RH --show-item=repos-size 
> ^/subversion/developer-resources/difftools
> 66 B   
> https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/README

[...]

On second thought, I think I should revert this. Consider the
inconsistency with --show-item=last-changed-date:

$ svn info ^/subversion/trunk/CHANGES --human-readable 
--show-item=last-changed-date
2018-11-26T02:50:47.513639Z

but

$ svn info ^/subversion/trunk/CHANGES | grep '^Last Changed Date'
Last Changed Date: 2018-11-26 03:50:47 +0100 (Mon, 26 Nov 2018)


The output from --show-item was always meant to be strictly for scripts.

-- Brane

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 26.11.2018 04:15, Daniel Shahaf wrote:
> Branko Čibej wrote on Sun, 25 Nov 2018 23:28 +0100:
>> On 25.11.2018 18:42, Branko Čibej wrote:
>>> On 25.11.2018 11:58, Daniel Shahaf wrote:
 Branko Čibej wrote on Sun, 25 Nov 2018 06:06 +0100:
> $ svn ls --verbose --human-readable
> 1847281 stsp  Nov 23 16:04 ./
> 1716820 rhuijben 175B Nov 27  2015 .editorconfig
 'svn info' doesn't print file sizes at all.  If it did, it could take
 the new flag too.
>>> svn info -H --show-item=size? :)
>> But seriouisly '--human-readable' and '--show-item' would be incompatible.
> I don't see why.  It would make perfect sense to have:
> .
> % svn info --human-readable --show-item=repos-size
> 42KiB
> % 
> .
> for interactive usage.


This?


$ svn info -RH --show-item=repos-size ^/subversion/developer-resources/difftools
66 B   
https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/README
57 B   
https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/README
20 KiB 
https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/FileMerge1.jpg
30 KiB 
https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/FileMerge2.jpg
90 KiB 
https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/FileMerge3.jpg
115 KiB
https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/FileMerge4.jpg
84 KiB 
https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/FileMerge5.jpg
1.1 KiB
https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/xxdiff-README
17 KiB 
https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/xxdiff-1.png
464 B  
https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/FileMerge-README



-- Brane

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 26.11.2018 16:30, Vincent Lefevre wrote:
> On 2018-11-26 15:18:47 +0100, Branko Čibej wrote:
>> Do please read the rest of the thread. A solution has already been
>> implemented on trunk.
> Except that this solution is not satisfactory for me. I guess that
> the ultimate solution is to use --xml + a wrapper (thus one could
> add things like coloring), though that's still limited as one
> doesn't get the MIME type (svn:mime-type).

I'm delighted that you have a solution. Job done.

-- Brane

Re: truncated author names in 'svn ls -v' output

[Stefan Sperling]

On Mon, Nov 26, 2018 at 04:30:27PM +0100, Vincent Lefevre wrote:
> On 2018-11-26 15:18:47 +0100, Branko Čibej wrote:
> > Do please read the rest of the thread. A solution has already been
> > implemented on trunk.
> 
> Except that this solution is not satisfactory for me. I guess that
> the ultimate solution is to use --xml + a wrapper (thus one could
> add things like coloring), though that's still limited as one
> doesn't get the MIME type (svn:mime-type).

Please don't poke our grumpy Brane bear; we need him to stay in a good mood.
You see, if you don't like Brane's solution, and you already have a
working alternative of your own invention which you prefer anyway, then
pointing out that Brane's solution is unsatisfactory to you just comes
across as... kind of rude. Even if not meant that way, this was certainly
not a constructive comment to make on a mailing list such as this one.

Re: truncated author names in 'svn ls -v' output

[Vincent Lefevre]

On 2018-11-26 15:18:47 +0100, Branko Čibej wrote:
> Do please read the rest of the thread. A solution has already been
> implemented on trunk.

Except that this solution is not satisfactory for me. I guess that
the ultimate solution is to use --xml + a wrapper (thus one could
add things like coloring), though that's still limited as one
doesn't get the MIME type (svn:mime-type).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 26.11.2018 15:11, Vincent Lefevre wrote:
> On 2018-11-23 09:10:50 +0100, Stefan Sperling wrote:
>> At 16 columns, name collisions become far less likely. In our own project,
>> the output would now look like this:
> [...]
>
> Yes, but this makes less space for long filenames.
>
> Why not make this size user-configurable, so that each user may choose
> which size is best for him? (Ideally one should be able to choose a
> configuration that depends on the repository.)


We have far too many configuration knobs already, adding more for output
formatting is just overkill. Especially when it's not necessary.


> So...
>
>> Index: subversion/svn/list-cmd.c
>> ===
>> --- subversion/svn/list-cmd.c(revision 1846851)
>> +++ subversion/svn/list-cmd.c(working copy)
>> @@ -150,7 +150,7 @@ print_dirent(void *baton,
>>   dirent->size);
>>  
>>return svn_cmdline_printf
>> -  (scratch_pool, "%7ld %-8.8s %c %10s %12s %s%s\n",
>> +  (scratch_pool, "%7ld %-16.16s %c %10s %12s %s%s\n",
>> dirent->created_rev,
>> dirent->last_author ? dirent->last_author : " ? ",
>> lock ? 'O' : ' ',
> You could use * for the width and precision fields.

Do please read the rest of the thread. A solution has already been
implemented on trunk.

-- Brane

Re: truncated author names in 'svn ls -v' output

[Vincent Lefevre]

On 2018-11-23 09:10:50 +0100, Stefan Sperling wrote:
> At 16 columns, name collisions become far less likely. In our own project,
> the output would now look like this:
[...]

Yes, but this makes less space for long filenames.

Why not make this size user-configurable, so that each user may choose
which size is best for him? (Ideally one should be able to choose a
configuration that depends on the repository.)

So...

> Index: subversion/svn/list-cmd.c
> ===
> --- subversion/svn/list-cmd.c (revision 1846851)
> +++ subversion/svn/list-cmd.c (working copy)
> @@ -150,7 +150,7 @@ print_dirent(void *baton,
>   dirent->size);
>  
>return svn_cmdline_printf
> -  (scratch_pool, "%7ld %-8.8s %c %10s %12s %s%s\n",
> +  (scratch_pool, "%7ld %-16.16s %c %10s %12s %s%s\n",
> dirent->created_rev,
> dirent->last_author ? dirent->last_author : " ? ",
> lock ? 'O' : ' ',

You could use * for the width and precision fields.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: truncated author names in 'svn ls -v' output

[Daniel Shahaf]

Branko Čibej wrote on Mon, 26 Nov 2018 06:13 +0100:
> On 26.11.2018 05:58, Daniel Shahaf wrote:
> >>> (we needn't support other values (except perhaps --base=1 for the 1.11 
> >>> behaviour))
> >> ?:\  Which behaviour?
> > The default behaviour: printing the filesize as an integer (possibly with
> > thousands separator).  Mathematically, base-2 means the printed value N
> > stands for N * 2**foo, so the 1.11 behaviour is equivalent to --unit-base=1.
> 
> Ah! this is "1.11" the version number, not "1.11" some magical base-1
> number format. For a moment I was worried about having to print
> thousands of 1's. :)

Yes, the version number :-D

> > It might be clearer to just call it --unit-base=none.
> 
> But do we really need to support this option value explicitly? The
> absence of the option already asserts the default behaviour.

I was thinking of --accept, where one can do 'svn merge --accept=tf 
--accept=postpone';
but that's not possible with, say, -v, where one can't do 'svn ls -v --no-v'.

*shrug*

Daniel

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 26.11.2018 05:58, Daniel Shahaf wrote:
>>> (we needn't support other values (except perhaps --base=1 for the 1.11 
>>> behaviour))
>> ?:\  Which behaviour?
> The default behaviour: printing the filesize as an integer (possibly with
> thousands separator).  Mathematically, base-2 means the printed value N
> stands for N * 2**foo, so the 1.11 behaviour is equivalent to --unit-base=1.

Ah! this is "1.11" the version number, not "1.11" some magical base-1
number format. For a moment I was worried about having to print
thousands of 1's. :)

Nitpick: the base-2 units are actually base-2^10, and the base-10 units
are really base-10^3.


> It might be clearer to just call it --unit-base=none.

But do we really need to support this option value explicitly? The
absence of the option already asserts the default behaviour.

-- Brane

Re: truncated author names in 'svn ls -v' output

[Daniel Shahaf]

Branko Čibej wrote on Mon, 26 Nov 2018 05:38 +0100:
> I really like the idea of 'svn ls -vH' as a sort of mnemonic of 'ls -lh'.
> Note that whilst the actual option letters are different -- on
> purpose, we had a long discussion about -v vs. -l a long time ago -- the
> use of single-letter options in this case would be nice. I suspect -H
> would be used almost as often as -v, but no-one would probably bother
> with --human-readable. (OK, bash-completion helps.)

I don't run 'svn ls' often.

> >> I'd though about adding a --base-10 flag, so '-H' is base-2 units and
> >> '-H --base-10' would use base-10 units. I do think that the default
> >> should be base-2, because users are probably more used to thinking that
> >> way. Well, at least programmers are, and they are, after all, the main
> >> users of version control.
> > I'm not a fan of having one flag modify another flag's meaning.  I'd prefer
> >
> > --base=2
> > --base=10
> 
> Not so bad. I'd call it --unit-base then, to avoid confusion with number
> bases.
> 
> > (we needn't support other values (except perhaps --base=1 for the 1.11 
> > behaviour))
> 
> ?:\  Which behaviour?

The default behaviour: printing the filesize as an integer (possibly with
thousands separator).  Mathematically, base-2 means the printed value N
stands for N * 2**foo, so the 1.11 behaviour is equivalent to --unit-base=1.

It might be clearer to just call it --unit-base=none.

> > I suppose we could then have --human-readable as "currently, an alias to
> > --base=10", with an option to extend it --- like 'diff --patch-compatible'.
> 
> I like this approach. But I'd make --human-readable === --unit-base=2,
> for reasons already mentioned.

Sorry, yes.  In context of filesizes base-2 as default makes sense.

>

Re: truncated author names in 'svn ls -v' output

[Daniel Shahaf]

Branko Čibej wrote on Sun, 25 Nov 2018 18:51 +0100:
> It's just a damn shame that the '-h' flag is already taken, otherwise we
> could be like 'df' and use -h for base-2 units and -H for base-10 units,
> whereas now it's -H for base-2 units ... if anyone has any bright ideas
> for fixing this omission, please say so.

We've traditionally been careful about not using up the one-letter-option
space.  Are we sure that this merits *two* one-letter option?

> I'd though about adding a --base-10 flag, so '-H' is base-2 units and
> '-H --base-10' would use base-10 units. I do think that the default
> should be base-2, because users are probably more used to thinking that
> way. Well, at least programmers are, and they are, after all, the main
> users of version control.

I'm not a fan of having one flag modify another flag's meaning.  I'd prefer

--base=2
--base=10

(we needn't support other values (except perhaps --base=1 for the 1.11 
behaviour))

I suppose we could then have --human-readable as "currently, an alias to
--base=10", with an option to extend it --- like 'diff --patch-compatible'.

> Ah, right: r1847422 fixes a silly bug in the number scaling, but more
> importantly it changes the number formatting to use the locale-specific
> decimal separator, to make it consistent with the locale-specific date
> abbreviation:

I'm just glad there's no such thing as locale-specific SI prefixes.
(What's a kilobyte in imperial?)

> $ env LC_ALL="it_IT.UTF-8" svn ls -vH
> 1847281 stsp  Nov 23 16:04 ./
> 1716820 rhuijben 175B Nov 27  2015 .editorconfig
> 1659509 rhuijben 3,0K Feb 13  2015 .ycm_extra_conf.py   <<<**!
>  915036 mf94B Feb 22  2010 BUGS
> 1846422 julianfoad   347K Nov 12 15:26 CHANGES
> 1833511 julianfoad14K Giu 14 16:40 COMMITTERS
> 1829224 astieger  55K Apr 15  2018 INSTALL
> 1801940 kotkov22K Lug 14  2017 LICENSE
> 1845942 brane 42K Nov 06 18:37 Makefile.in

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 26.11.2018 04:15, Daniel Shahaf wrote:
> Branko Čibej wrote on Sun, 25 Nov 2018 23:28 +0100:
>> On 25.11.2018 18:42, Branko Čibej wrote:
>>> On 25.11.2018 11:58, Daniel Shahaf wrote:
 Branko Čibej wrote on Sun, 25 Nov 2018 06:06 +0100:
> $ svn ls --verbose --human-readable
> 1847281 stsp  Nov 23 16:04 ./
> 1716820 rhuijben 175B Nov 27  2015 .editorconfig
 'svn info' doesn't print file sizes at all.  If it did, it could take
 the new flag too.
>>> svn info -H --show-item=size? :)
>> But seriouisly '--human-readable' and '--show-item' would be incompatible.
> I don't see why.  It would make perfect sense to have:
> .
> % svn info --human-readable --show-item=repos-size
> 42KiB
> % 
> .
> for interactive usage.

Easily added if we want it. Note that when we use the whole unit, not
just its magnitude prefix (KiB vs. K), there should be a space between
the number and the unit; so, "42 KiB" not "42KiB". And that's what we do
now in the normal 'svn info' output. Incidentally that makes parsing the
"human-readable" output in scripts easier, too ...

Just now I committed r1847448 which adds a function that does the same
conversion in base-10 units. However I've not yet wired it into the
options and commands.

-- Brane

Re: truncated author names in 'svn ls -v' output

[Daniel Shahaf]

Branko Čibej wrote on Sun, 25 Nov 2018 23:28 +0100:
> On 25.11.2018 18:42, Branko Čibej wrote:
> > On 25.11.2018 11:58, Daniel Shahaf wrote:
> >> Branko Čibej wrote on Sun, 25 Nov 2018 06:06 +0100:
> >>> $ svn ls --verbose --human-readable
> >>> 1847281 stsp  Nov 23 16:04 ./
> >>> 1716820 rhuijben 175B Nov 27  2015 .editorconfig
> >> 'svn info' doesn't print file sizes at all.  If it did, it could take
> >> the new flag too.
> > svn info -H --show-item=size? :)
> 
> But seriouisly '--human-readable' and '--show-item' would be incompatible.

I don't see why.  It would make perfect sense to have:
.
% svn info --human-readable --show-item=repos-size
42KiB
% 
.
for interactive usage.

> Is r1847441 an acceptable starting point? It doesn't handle
> '--human-readable' yet, because I wanted to keep the two commits separate.

Kudos. :)

Daniel

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 25.11.2018 23:28, Branko Čibej wrote:
> On 25.11.2018 18:42, Branko Čibej wrote:
>> On 25.11.2018 11:58, Daniel Shahaf wrote:
>>> Branko Čibej wrote on Sun, 25 Nov 2018 06:06 +0100:
 $ svn ls --verbose --human-readable
 1847281 stsp  Nov 23 16:04 ./
 1716820 rhuijben 175B Nov 27  2015 .editorconfig
>>> 'svn info' doesn't print file sizes at all.  If it did, it could take
>>> the new flag too.
>> svn info -H --show-item=size? :)
> But seriouisly '--human-readable' and '--show-item' would be incompatible.
>
> Is r1847441 an acceptable starting point? It doesn't handle
> '--human-readable' yet, because I wanted to keep the two commits separate.

With r1847441:

svn info  ^/subversion/trunk/CHANGES
Path: CHANGES
Name: CHANGES
URL: https://svn.apache.org/repos/asf/subversion/trunk/CHANGES
Relative URL: ^/subversion/trunk/CHANGES
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1847443
Node Kind: file
Size in Repository: 355019   <<<**
Last Changed Author: brane
Last Changed Rev: 1847423
Last Changed Date: 2018-11-25 18:36:21 +0100 (Sun, 25 Nov 2018)



With r1847443:

$ svn info -H ^/subversion/trunk/CHANGES
Path: CHANGES
...
Size in Repository: 347 KiB
...


-- Brane

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 25.11.2018 18:42, Branko Čibej wrote:
> On 25.11.2018 11:58, Daniel Shahaf wrote:
>> Branko Čibej wrote on Sun, 25 Nov 2018 06:06 +0100:
>>> $ svn ls --verbose --human-readable
>>> 1847281 stsp  Nov 23 16:04 ./
>>> 1716820 rhuijben 175B Nov 27  2015 .editorconfig
>> 'svn info' doesn't print file sizes at all.  If it did, it could take
>> the new flag too.
> svn info -H --show-item=size? :)

But seriouisly '--human-readable' and '--show-item' would be incompatible.

Is r1847441 an acceptable starting point? It doesn't handle
'--human-readable' yet, because I wanted to keep the two commits separate.

-- Brane

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 25.11.2018 10:53, Stefan Sperling wrote:
> On Sun, Nov 25, 2018 at 06:06:20AM +0100, Branko Čibej wrote:
>> On 23.11.2018 18:47, Branko Čibej wrote:
>>> On 23.11.2018 10:40, Daniel Shahaf wrote:
 Branko Čibej wrote on Fri, 23 Nov 2018 10:15 +0100:
> On 23.11.2018 09:10, Stefan Sperling wrote:
>> I would like make a change, but it is a highly bikesheddy one so
>> I'd rather ask the list first to give everyone a chance to suggest
>> their favourite colours.
>>
>> The length of author names in 'svn ls -v' output is currently truncated
>> at 8 columns. Things have been this way since the dawn of time:
>> https://svn.apache.org/r842817
> So it has, the idea was to make the output easily parseable with 'cut'
> etc. That was long before --xml.
 We already broke compatibility with cut(1) when we changed the first
 column's width from %6ld to %7ld.  Before that, the output was actually
 aligned with '/bin/ls -l' on my system.
>>> You're right. And of course, the fact that we've had --xml for a long
>>> time should simplify the decision.
>>>
>>> I have a couple of ideas ... will make up a patch over the week-end.
>> r1847384
>>
>> Does two new things; this:
>>
>> $ svn ls -v
>> 1847281 stsp  Nov 23 16:04 ./
>> 1716820 rhuijben  175 Nov 27  2015 .editorconfig
>> 1659509 rhuijben 3091 Feb 13  2015 .ycm_extra_conf.py
>>  915036 mf 94 Feb 22  2010 BUGS
>> 1846422 julianfoad   354869 Nov 12 15:26 CHANGES <<<**!
>> 1833511 julianfoad14264 Jun 14 16:40 COMMITTERS
>> 1829224 astieger  55966 Apr 15  2018 INSTALL
>> 1801940 kotkov22834 Jul 14  2017 LICENSE
>> 1845942 brane 42789 Nov 06 18:37 Makefile.in
>>
>>
>> And this:
>>
>> $ svn ls --verbose --human-readable
>> 1847281 stsp  Nov 23 16:04 ./
>> 1716820 rhuijben 175B Nov 27  2015 .editorconfig
>> 1659509 rhuijben 3.0K Feb 13  2015 .ycm_extra_conf.py
>>  915036 mf94B Feb 22  2010 BUGS
>> 1846422 julianfoad   347K Nov 12 15:26 CHANGES
>> 1833511 julianfoad14K Jun 14 16:40 COMMITTERS
>> 1829224 astieger  55K Apr 15  2018 INSTALL
>> 1801940 kotkov22K Jul 14  2017 LICENSE
>> 1845942 brane 42K Nov 06 18:37 Makefile.in
>>
>>
>> And for example, once GitHub is fixed, this:
>>
>> $ svn ls -vH https://github.com/apache/httpd/trunk
>>   59613 jean.frederic.clereNov 23 18:10 ./
>>   59436 ruediger.pluem 15K Oct 26 12:24 .gdbinit
>>   29451 jim.jagielski  13K Jan 04  2017 ABOUT_APACHE
>>   58200 gregg.lewis.smith  68K Feb 26  2018 Apache-apr2.dsw
>>   58200 gregg.lewis.smith  84K Feb 26  2018 Apache.dsw
>>   16350 william.a..rowe.jr2.6K Aug 24  2007 BuildAll.dsp
>>   57872 gregg.lewis.smith 2.7K Jan 19  2018 BuildBin.dsp
>>   59450 christophe.jaillet 33K Nov 11 09:22 CHANGES
>>   59174 jim.jagielski  49K Aug 09 13:30 CMakeLists.txt
>>
>>
>> -- Brane
>>
> Awesome, thank you!

It's just a damn shame that the '-h' flag is already taken, otherwise we
could be like 'df' and use -h for base-2 units and -H for base-10 units,
whereas now it's -H for base-2 units ... if anyone has any bright ideas
for fixing this omission, please say so.

I'd though about adding a --base-10 flag, so '-H' is base-2 units and
'-H --base-10' would use base-10 units. I do think that the default
should be base-2, because users are probably more used to thinking that
way. Well, at least programmers are, and they are, after all, the main
users of version control.

Ah, right: r1847422 fixes a silly bug in the number scaling, but more
importantly it changes the number formatting to use the locale-specific
decimal separator, to make it consistent with the locale-specific date
abbreviation:

$ env LC_ALL="it_IT.UTF-8" svn ls -vH
1847281 stsp  Nov 23 16:04 ./
1716820 rhuijben 175B Nov 27  2015 .editorconfig
1659509 rhuijben 3,0K Feb 13  2015 .ycm_extra_conf.py   <<<**!
 915036 mf94B Feb 22  2010 BUGS
1846422 julianfoad   347K Nov 12 15:26 CHANGES
1833511 julianfoad14K Giu 14 16:40 COMMITTERS
1829224 astieger  55K Apr 15  2018 INSTALL
1801940 kotkov22K Lug 14  2017 LICENSE
1845942 brane 42K Nov 06 18:37 Makefile.in



-- Brane

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 25.11.2018 11:58, Daniel Shahaf wrote:
> Branko Čibej wrote on Sun, 25 Nov 2018 06:06 +0100:
>> $ svn ls --verbose --human-readable
>> 1847281 stsp  Nov 23 16:04 ./
>> 1716820 rhuijben 175B Nov 27  2015 .editorconfig
> 'svn info' doesn't print file sizes at all.  If it did, it could take
> the new flag too.

svn info -H --show-item=size? :)

Re: truncated author names in 'svn ls -v' output

[Daniel Shahaf]

Branko Čibej wrote on Sun, 25 Nov 2018 06:06 +0100:
> $ svn ls --verbose --human-readable
> 1847281 stsp  Nov 23 16:04 ./
> 1716820 rhuijben 175B Nov 27  2015 .editorconfig

'svn info' doesn't print file sizes at all.  If it did, it could take
the new flag too.

Re: truncated author names in 'svn ls -v' output

[Stefan Sperling]

On Sun, Nov 25, 2018 at 06:06:20AM +0100, Branko Čibej wrote:
> On 23.11.2018 18:47, Branko Čibej wrote:
> > On 23.11.2018 10:40, Daniel Shahaf wrote:
> >> Branko Čibej wrote on Fri, 23 Nov 2018 10:15 +0100:
> >>> On 23.11.2018 09:10, Stefan Sperling wrote:
>  I would like make a change, but it is a highly bikesheddy one so
>  I'd rather ask the list first to give everyone a chance to suggest
>  their favourite colours.
> 
>  The length of author names in 'svn ls -v' output is currently truncated
>  at 8 columns. Things have been this way since the dawn of time:
>  https://svn.apache.org/r842817
> >>> So it has, the idea was to make the output easily parseable with 'cut'
> >>> etc. That was long before --xml.
> >> We already broke compatibility with cut(1) when we changed the first
> >> column's width from %6ld to %7ld.  Before that, the output was actually
> >> aligned with '/bin/ls -l' on my system.
> > You're right. And of course, the fact that we've had --xml for a long
> > time should simplify the decision.
> >
> > I have a couple of ideas ... will make up a patch over the week-end.
> 
> r1847384
> 
> Does two new things; this:
> 
> $ svn ls -v
> 1847281 stsp  Nov 23 16:04 ./
> 1716820 rhuijben  175 Nov 27  2015 .editorconfig
> 1659509 rhuijben 3091 Feb 13  2015 .ycm_extra_conf.py
>  915036 mf 94 Feb 22  2010 BUGS
> 1846422 julianfoad   354869 Nov 12 15:26 CHANGES <<<**!
> 1833511 julianfoad14264 Jun 14 16:40 COMMITTERS
> 1829224 astieger  55966 Apr 15  2018 INSTALL
> 1801940 kotkov22834 Jul 14  2017 LICENSE
> 1845942 brane 42789 Nov 06 18:37 Makefile.in
> 
> 
> And this:
> 
> $ svn ls --verbose --human-readable
> 1847281 stsp  Nov 23 16:04 ./
> 1716820 rhuijben 175B Nov 27  2015 .editorconfig
> 1659509 rhuijben 3.0K Feb 13  2015 .ycm_extra_conf.py
>  915036 mf94B Feb 22  2010 BUGS
> 1846422 julianfoad   347K Nov 12 15:26 CHANGES
> 1833511 julianfoad14K Jun 14 16:40 COMMITTERS
> 1829224 astieger  55K Apr 15  2018 INSTALL
> 1801940 kotkov22K Jul 14  2017 LICENSE
> 1845942 brane 42K Nov 06 18:37 Makefile.in
> 
> 
> And for example, once GitHub is fixed, this:
> 
> $ svn ls -vH https://github.com/apache/httpd/trunk
>   59613 jean.frederic.clereNov 23 18:10 ./
>   59436 ruediger.pluem 15K Oct 26 12:24 .gdbinit
>   29451 jim.jagielski  13K Jan 04  2017 ABOUT_APACHE
>   58200 gregg.lewis.smith  68K Feb 26  2018 Apache-apr2.dsw
>   58200 gregg.lewis.smith  84K Feb 26  2018 Apache.dsw
>   16350 william.a..rowe.jr2.6K Aug 24  2007 BuildAll.dsp
>   57872 gregg.lewis.smith 2.7K Jan 19  2018 BuildBin.dsp
>   59450 christophe.jaillet 33K Nov 11 09:22 CHANGES
>   59174 jim.jagielski  49K Aug 09 13:30 CMakeLists.txt
> 
> 
> -- Brane
> 

Awesome, thank you!

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 23.11.2018 18:47, Branko Čibej wrote:
> On 23.11.2018 10:40, Daniel Shahaf wrote:
>> Branko Čibej wrote on Fri, 23 Nov 2018 10:15 +0100:
>>> On 23.11.2018 09:10, Stefan Sperling wrote:
 I would like make a change, but it is a highly bikesheddy one so
 I'd rather ask the list first to give everyone a chance to suggest
 their favourite colours.

 The length of author names in 'svn ls -v' output is currently truncated
 at 8 columns. Things have been this way since the dawn of time:
 https://svn.apache.org/r842817
>>> So it has, the idea was to make the output easily parseable with 'cut'
>>> etc. That was long before --xml.
>> We already broke compatibility with cut(1) when we changed the first
>> column's width from %6ld to %7ld.  Before that, the output was actually
>> aligned with '/bin/ls -l' on my system.
> You're right. And of course, the fact that we've had --xml for a long
> time should simplify the decision.
>
> I have a couple of ideas ... will make up a patch over the week-end.

r1847384

Does two new things; this:

$ svn ls -v
1847281 stsp  Nov 23 16:04 ./
1716820 rhuijben  175 Nov 27  2015 .editorconfig
1659509 rhuijben 3091 Feb 13  2015 .ycm_extra_conf.py
 915036 mf 94 Feb 22  2010 BUGS
1846422 julianfoad   354869 Nov 12 15:26 CHANGES <<<**!
1833511 julianfoad14264 Jun 14 16:40 COMMITTERS
1829224 astieger  55966 Apr 15  2018 INSTALL
1801940 kotkov22834 Jul 14  2017 LICENSE
1845942 brane 42789 Nov 06 18:37 Makefile.in


And this:

$ svn ls --verbose --human-readable
1847281 stsp  Nov 23 16:04 ./
1716820 rhuijben 175B Nov 27  2015 .editorconfig
1659509 rhuijben 3.0K Feb 13  2015 .ycm_extra_conf.py
 915036 mf94B Feb 22  2010 BUGS
1846422 julianfoad   347K Nov 12 15:26 CHANGES
1833511 julianfoad14K Jun 14 16:40 COMMITTERS
1829224 astieger  55K Apr 15  2018 INSTALL
1801940 kotkov22K Jul 14  2017 LICENSE
1845942 brane 42K Nov 06 18:37 Makefile.in


And for example, once GitHub is fixed, this:

$ svn ls -vH https://github.com/apache/httpd/trunk
  59613 jean.frederic.clereNov 23 18:10 ./
  59436 ruediger.pluem 15K Oct 26 12:24 .gdbinit
  29451 jim.jagielski  13K Jan 04  2017 ABOUT_APACHE
  58200 gregg.lewis.smith  68K Feb 26  2018 Apache-apr2.dsw
  58200 gregg.lewis.smith  84K Feb 26  2018 Apache.dsw
  16350 william.a..rowe.jr2.6K Aug 24  2007 BuildAll.dsp
  57872 gregg.lewis.smith 2.7K Jan 19  2018 BuildBin.dsp
  59450 christophe.jaillet 33K Nov 11 09:22 CHANGES
  59174 jim.jagielski  49K Aug 09 13:30 CMakeLists.txt


-- Brane

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 23.11.2018 10:40, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, 23 Nov 2018 10:15 +0100:
>> On 23.11.2018 09:10, Stefan Sperling wrote:
>>> I would like make a change, but it is a highly bikesheddy one so
>>> I'd rather ask the list first to give everyone a chance to suggest
>>> their favourite colours.
>>>
>>> The length of author names in 'svn ls -v' output is currently truncated
>>> at 8 columns. Things have been this way since the dawn of time:
>>> https://svn.apache.org/r842817
>> So it has, the idea was to make the output easily parseable with 'cut'
>> etc. That was long before --xml.
> We already broke compatibility with cut(1) when we changed the first
> column's width from %6ld to %7ld.  Before that, the output was actually
> aligned with '/bin/ls -l' on my system.

You're right. And of course, the fact that we've had --xml for a long
time should simplify the decision.

I have a couple of ideas ... will make up a patch over the week-end.

-- Brane

Re: truncated author names in 'svn ls -v' output

[Daniel Shahaf]

Branko Čibej wrote on Fri, 23 Nov 2018 10:15 +0100:
> On 23.11.2018 09:10, Stefan Sperling wrote:
> > I would like make a change, but it is a highly bikesheddy one so
> > I'd rather ask the list first to give everyone a chance to suggest
> > their favourite colours.
> >
> > The length of author names in 'svn ls -v' output is currently truncated
> > at 8 columns. Things have been this way since the dawn of time:
> > https://svn.apache.org/r842817
> 
> So it has, the idea was to make the output easily parseable with 'cut'
> etc. That was long before --xml.

We already broke compatibility with cut(1) when we changed the first
column's width from %6ld to %7ld.  Before that, the output was actually
aligned with '/bin/ls -l' on my system.

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 23.11.2018 09:10, Stefan Sperling wrote:
> I would like make a change, but it is a highly bikesheddy one so
> I'd rather ask the list first to give everyone a chance to suggest
> their favourite colours.
>
> The length of author names in 'svn ls -v' output is currently truncated
> at 8 columns. Things have been this way since the dawn of time:
> https://svn.apache.org/r842817

So it has, the idea was to make the output easily parseable with 'cut'
etc. That was long before --xml.


> Note that this limit is actually rather short and causes truncation
> of names even in our own project (hey, Julian!):
>
> $ svn ls -v
> 1846851 stsp  Nov 18 17:42 ./
> 1716820 rhuijben  175 Nov 27  2015 .editorconfig
[...]
> Now, I've had in inquiry from an organization where conventional usernames
> follow a FirstName.LastName style. Under this scheme, my own name would
> be indistinguishable from that of Eastern European soccer players Stefan

Surely you mean football players?

> Spremo and Stefan Spirovski. While I find this flattering, I don't think

Don't be flattered, football players make a living using their heads,
just like you, only slightly differently.

> these soccer players would enjoy getting mixed up with each other, let
> alone getting mixed up with me!
>
> One way to address this problem is to increase the minimum field width.
> Using a fixed width is a good approach because dirents are being printed
> as they stream down from the server. The client has no way of knowing the
> length of the longest author name within a given directory ahead of time.
> Unless, of course, we also changed the client to buffer dirents before
> printing them. But I'm hesitent to do that when a simpler solution exists.
>
> At 16 columns, name collisions become far less likely. In our own project,
> the output would now look like this:
>
> $ svn ls -v
> 1846851 stsp  Nov 18 17:42 ./
> 1716820 rhuijben  175 Nov 27  2015 .editorconfig
> 1659509 rhuijben 3091 Feb 13  2015 .ycm_extra_conf.py
>  915036 mf 94 Feb 22  2010 BUGS
[...]
> Note that we have fairly short paths. But anyone who actually uses long
> paths (Java developers, for example) will already see overflowing lines
> under the existing author truncation rules anyway.
>
> I know of two workarounds:
>
>  Use 'svn log --xml', but this is not as readable.
>
>  Use 'svn info' to see the full name for a specific entry, but this
>  is not as convenient.
>
>
> Any objections to this idea?

If we decide to break historic scripts that don't use --xml, we may as
well try to be smarter and try to guess the longest username. However
this would really become a problem with 'svn ls -R', which may return a
_LOT_ of data and doesn't conveniently partition its output the way that
plain 'ls -R' does.

Note that svn:author is not the only problem, we also leave only 10
columns for the file size, which might not be enough these days. But on
the other hand, that column /will/ expand when necessary.

There is one thing we could do without waiting for complete output.
Start with a column width of, say, 10; but track the size of the
svn:author field and if it's longer, increase the field size for
subsequent lines.

That can cause the output to look strange in some cases, but at least
it's likely to be consistent most of the time. (Also 10 columns is
enough for 'julianfoad', which is really the most important
consideration here ... :)

-- Brane