truncated author names in 'svn ls -v' output

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

truncated author names in 'svn ls -v' output

Stefan Sperling
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

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
1659509 rhuijben         3091 Feb 13  2015 .ycm_extra_conf.py
 915036 mf                 94 Feb 22  2010 BUGS
1846422 julianfo       354869 Nov 12 15:26 CHANGES
1833511 julianfo        14264 Jun 14 16:40 COMMITTERS
1829224 astieger        55966 Apr 15  2018 INSTALL
1801940 kotkov          22834 Jul 14  2017 LICENSE
1845942 brane           42789 Nov 06 18:37 Makefile.in
1819747 danielsh         1254 Jan 01  2018 NOTICE
1746277 luke1410         2256 May 31  2016 README
1803210 philip           2142 Jul 27  2017 aclocal.m4
1692448 danielsh         7726 Jul 23  2015 autogen.sh
1845942 brane                 Nov 06 18:37 build/
1845716 brane           52115 Nov 04 06:49 build.conf
1845555 jorton          56811 Nov 02 10:23 configure.ac
1838541 danielsh              Aug 21 13:57 contrib/
1837041 julianfo              Jul 30 12:25 doc/
1822798 rhuijben        10922 Jan 31  2018 gen-make.py
1817043 kotkov           5322 Dec 03  2017 get-deps.sh
1845066 esr                   Oct 28 22:14 notes/
1846851 stsp                  Nov 18 17:42 subversion/
1846328 brane                 Nov 11 06:54 tools/
1813897 stsp            48359 Oct 31  2017 win-tests.py

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
Spremo and Stefan Spirovski. While I find this flattering, I don't think
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
1846422 julianfoad             354869 Nov 12 15:26 CHANGES
1833511 julianfoad              14264 Jun 14 16:40 COMMITTERS
1829224 astieger                55966 Apr 15  2018 INSTALL
1801940 kotkov                  22834 Jul 14  2017 LICENSE
1845942 brane                   42789 Nov 06 18:37 Makefile.in
1819747 danielsh                 1254 Jan 01  2018 NOTICE
1746277 luke1410                 2256 May 31  2016 README
1803210 philip                   2142 Jul 27  2017 aclocal.m4
1692448 danielsh                 7726 Jul 23  2015 autogen.sh
1845942 brane                         Nov 06 18:37 build/
1845716 brane                   52115 Nov 04 06:49 build.conf
1845555 jorton                  56811 Nov 02 10:23 configure.ac
1838541 danielsh                      Aug 21 13:57 contrib/
1837041 julianfoad                    Jul 30 12:25 doc/
1822798 rhuijben                10922 Jan 31  2018 gen-make.py
1817043 kotkov                   5322 Dec 03  2017 get-deps.sh
1845066 esr                           Oct 28 22:14 notes/
1846851 stsp                          Nov 18 17:42 subversion/
1846328 brane                         Nov 11 06:54 tools/
1813897 stsp                    48359 Oct 31  2017 win-tests.py

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?

I haven't run tests on this patch yet.

[[[
* subversion/svn/list-cmd.c
  (print_dirent): Give more space to names of authors.
]]]

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' : ' ',
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
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.
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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 julianfoad        14264 Jun 14 16:40 COMMITTERS
1829224 astieger          55966 Apr 15  2018 INSTALL
1801940 kotkov            22834 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 mf                94B Feb 22  2010 BUGS
1846422 julianfoad       347K Nov 12 15:26 CHANGES
1833511 julianfoad        14K Jun 14 16:40 COMMITTERS
1829224 astieger          55K Apr 15  2018 INSTALL
1801940 kotkov            22K 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.clere        Nov 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.jr    2.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

Reply | Threaded
Open this post in threaded view
|

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 julianfoad        14264 Jun 14 16:40 COMMITTERS
> 1829224 astieger          55966 Apr 15  2018 INSTALL
> 1801940 kotkov            22834 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 mf                94B Feb 22  2010 BUGS
> 1846422 julianfoad       347K Nov 12 15:26 CHANGES
> 1833511 julianfoad        14K Jun 14 16:40 COMMITTERS
> 1829224 astieger          55K Apr 15  2018 INSTALL
> 1801940 kotkov            22K 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.clere        Nov 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.jr    2.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!
Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
In reply to this post by Branko Čibej
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.
Reply | Threaded
Open this post in threaded view
|

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? :)

Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
In reply to this post by Stefan Sperling
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 julianfoad        14264 Jun 14 16:40 COMMITTERS
>> 1829224 astieger          55966 Apr 15  2018 INSTALL
>> 1801940 kotkov            22834 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 mf                94B Feb 22  2010 BUGS
>> 1846422 julianfoad       347K Nov 12 15:26 CHANGES
>> 1833511 julianfoad        14K Jun 14 16:40 COMMITTERS
>> 1829224 astieger          55K Apr 15  2018 INSTALL
>> 1801940 kotkov            22K 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.clere        Nov 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.jr    2.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 mf                94B Feb 22  2010 BUGS
1846422 julianfoad       347K Nov 12 15:26 CHANGES
1833511 julianfoad        14K Giu 14 16:40 COMMITTERS
1829224 astieger          55K Apr 15  2018 INSTALL
1801940 kotkov            22K Lug 14  2017 LICENSE
1845942 brane             42K Nov 06 18:37 Makefile.in



-- Brane

Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
In reply to this post by 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

Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
In reply to this post by Branko Čibej
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
Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
In reply to this post by Branko Čibej
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 mf                94B Feb 22  2010 BUGS
> 1846422 julianfoad       347K Nov 12 15:26 CHANGES
> 1833511 julianfoad        14K Giu 14 16:40 COMMITTERS
> 1829224 astieger          55K Apr 15  2018 INSTALL
> 1801940 kotkov            22K Lug 14  2017 LICENSE
> 1845942 brane             42K Nov 06 18:37 Makefile.in
Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
In reply to this post by Daniel Shahaf-2
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

Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
In reply to this post by Daniel Shahaf-2
On 26.11.2018 04:25, Daniel Shahaf wrote:
> 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 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'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?

> 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.

>> 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?)

That'll be 4d 7p and a farthing, thank you.

-- Brane

Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
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.

>
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
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
Reply | Threaded
Open this post in threaded view
|

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

Vincent Lefevre-11
In reply to this post by Stefan Sperling
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 <[hidden email]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply | Threaded
Open this post in threaded view
|

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

12