On 2020-01-16 10:37:05 +0000, Julian Foad wrote:
> 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);
Note that ls and git may be bad examples since they are both local
(well, for ls, directories can be remote such as via NFS or SSHFS,
but I don't think that it has been written primarily for such cases).
For ls, I've checked that the output is correctly aligned, even
in the case of several thousands of files followed by a file with
user/group names larger than 8 characters.
For svn, it depends whether you can accept to have all the data
before outputting anything. For me, it would be OK, even with
the -R option.
> 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.)
This does not really apply in the particular case of "svn ls -v" since
only some length would be cached. The user will not get "old" data.
Just possibly columns larger than needed in case some long author name
no longer exists.
> 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.
Note that caching the logs would really be useful, as this is often
very slow to get some old logs.
[...]
> 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.
This would really be great. Not to have ISO 8601 dates is also
annoying.
> 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.
Most tools have much flexibility (this includes ls and git). I suppose
that people use them.
Various tools use a printf-like format (e.g. Mutt, zsh).
> 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.
I agree.
> And we have recently mentioned adding other formats such as JSON,
> which may be more widely useful in today's software tooling
> ecosystem.
Except that there are more tools to parse XML than JSON.
--
Vincent Lefèvre <vincent@vinc17.net> - 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)
Received on 2020-01-17 12:33:59 CET