Branko Čibej wrote:
>> Why are we overthinking this?
Indeed. There is a lot of energy going in to this thread. It's great
to see energy and enthusiasm, but...
I know the current algorithm is sometimes annoying.
I accept sub-optimal decisions about it have been made in the past.
Any algorithm is going to be annoying in some cases. If we were ever to
change the algorithm, I suggest it would make sense to copy some well
known one (e.g. from an implementation of unix 'ls' or a git command);
it would not make sense to invent another one of our own. But it does
not makes sense to change the default algorithm again at all in svn 1.x
series. It would be resonable only as part of a complete redesign of
the command line interface some day.
Adding caching for this particular issue is really over-kill. Caching
is hard to get right. (One issue, for example, is how revision
properties can be modified on the server, and there is so far no
mechanism for efficiently letting clients find out about the changes.
That's one form of "stale cache" scenario to be figured out.)
On the other hand, if we invested in caching for more general use in the
client, and then got username length information "for free" out of that,
that would be a different matter.
The alternative to changing the default algorithm is to add an option to
control the output to the user's preference. It could be something as
specific as a setting for the column width to allow for the name column,
or as generic as specifying an output format template string, along the
lines of a "printf" format string.
I hate options. At least I hate lots of tiny specific-tweak options
like specifying the width of a particular column. For relatively
trivial things like this (compared with other svn problems; though I
know it can be annoying), please, no.
On the other hand, a more general configuration scheme to be able to
specify the output line format for each of the main svn commands would
be much more widely useful. It would have advantages such as being able
to generate abbreviated outputs tailored to certain use cases (e.g. in a
private repo, I might not care to see my username at all); or emulating
(to a limited extent) older versions of svn for compatibility with old
scripts.
From a business point of view it would be hard to justify adding that
flexibility -- it is hard to imagine many people making much use of it.
But the more generic it is (e.g., available for all commands the print
lines of output, not just 'ls' or just username fields) the more likely
it is to be found useful. As this is open source, if someone wants to
develop that, they can.
As I think out loud further down this road, I am thinking the fields
used in the format template string should correspond exactly to the
fields available in the XML output, using the same names. In fact the
line format output should be programmatically derivable from the XML.
And we have recently mentioned adding other formats such as JSON, which
may be more widely useful in today's software tooling ecosystem. They
should all be programmatically related, not implemented each according
to its own implementor's whims.
The important point I'm trying to draw out is that we can treat
something like as an opportunity to re-examine not just the micro scope
(a particular column width in 'ls') but the potential for improving
things more widely.
If the exercise leads to those sorts of improvements, +1.
If that's all too much for anyone to consider, I recommend either living
with the current imperfect behaviour or making a private patched version
and then offering that patch for anyone else to try, perhaps building
support for it that way.
- Julian
Received on 2020-01-16 11:37:08 CET