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' : ' ',

[Branko Čibej]

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

Post by Stefan Sperling
Note that this limit is actually rather short and causes truncation
$ svn ls -v
1846851 stsp Nov 18 17:42 ./
1716820 rhuijben 175 Nov 27 2015 .editorconfig

[...]

Post by Stefan Sperling
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?

Post by Stefan Sperling
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.

Post by Stefan Sperling
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,
$ 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

[...]

Post by Stefan Sperling
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.
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

[Daniel Shahaf]

Post by Branko Čibej

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

[Branko Čibej]

Post by Daniel Shahaf

Post by Branko Čibej

Post by 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
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

[Branko Čibej]

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej

Post by 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
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

[Stefan Sperling]

Post by Branko Čibej

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej

Post by 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
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
$ 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
$ 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
$ 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!

[Branko Čibej]

Post by Stefan Sperling

Post by Branko Čibej

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej

Post by 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
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
$ 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
$ 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
$ 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

[Daniel Shahaf]

Post by Branko Čibej
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?

Post by Branko Čibej
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'.

Post by Branko Čibej
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

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

Post by Branko Čibej
$ 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

[Branko Čibej]

Post by Daniel Shahaf

Post by Branko Čibej
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.)

Post by Daniel Shahaf

Post by Branko Čibej
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.

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

?:\  Which behaviour?

Post by Daniel Shahaf
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.

Post by Daniel Shahaf

Post by Branko Čibej
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

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

[Daniel Shahaf]

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.

Post by Daniel Shahaf

Post by Branko Čibej
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.

Post by Daniel Shahaf
(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.

Post by Daniel Shahaf
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.

[Branko Čibej]

Post by Daniel Shahaf

Post by Branko Čibej

Post by Daniel Shahaf
(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.

Post by Daniel Shahaf
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

[Daniel Shahaf]

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej

Post by Daniel Shahaf
(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

Post by Branko Čibej

Post by Daniel Shahaf
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

[Daniel Shahaf]

Post by Branko Čibej
$ 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.

[Branko Čibej]

Post by Daniel Shahaf

Post by Branko Čibej
$ 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? :)

[Branko Čibej]

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej
$ 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

[Branko Čibej]

Post by Branko Čibej

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej
$ 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

[Daniel Shahaf]

Post by Branko Čibej

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej
$ 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.

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

Kudos. :)

Daniel

[Branko Čibej]

Post by Daniel Shahaf

Post by Branko Čibej

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej
$ 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.

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

[Branko Čibej]

Post by Daniel Shahaf

Post by Branko Čibej

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej
$ 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.

.
% 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 Loading Image...
30 KiB Loading Image...
90 KiB Loading Image...
115 KiB Loading Image...
84 KiB Loading Image...
1.1 KiB https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/xxdiff-README
17 KiB Loading Image...
464 B https://svn.apache.org/repos/asf/subversion/developer-resources/difftools/pics/FileMerge-README



-- Brane

[Branko Čibej]

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej

Post by Branko Čibej

Post by Daniel Shahaf

Post by Branko Čibej
$ 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.

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

[Daniel Shahaf]

Post by Branko Čibej
On second thought, I think I should revert this. Consider the
$ 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

[Branko Čibej]

Post by Daniel Shahaf

Post by Branko Čibej
On second thought, I think I should revert this. Consider the
$ 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
.
.
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

[Vincent Lefevre]

Post by Stefan Sperling
At 16 columns, name collisions become far less likely. In our own project,

[...]

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

Post by Stefan Sperling
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.

[Branko Čibej]

Post by Vincent Lefevre

Post by Stefan Sperling
At 16 columns, name collisions become far less likely. In our own project,

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

Post by Vincent Lefevre
So...

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

[Vincent Lefevre]

Post by Branko Čibej
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).

[Stefan Sperling]

Post by Vincent Lefevre

Post by Branko Čibej
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.

[Vincent Lefevre]

Post by Stefan Sperling

Post by Vincent Lefevre

Post by Branko Čibej
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.

[Daniel Shahaf]

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)

[Vincent Lefevre]

Post by Daniel Shahaf

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

Post by Daniel Shahaf
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).

[Branko Čibej]

Post by Vincent Lefevre

Post by Daniel Shahaf

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.

Post by Vincent Lefevre

Post by Daniel Shahaf
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

[Vincent Lefevre]

Post by Branko Čibej

Post by Vincent Lefevre

Post by Daniel Shahaf
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.

[Branko Čibej]

Post by Vincent Lefevre

Post by Branko Čibej
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