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
Received on 2018-11-23 10:15:44 CET