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:

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

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

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

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

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.

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

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.

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:

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

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

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.

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

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

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

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.

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

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

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

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.