[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn list -v" column alignment issue

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Tue, 07 Jan 2020 17:24:38 +0000

Daniel Shahaf wrote on Tue, 07 Jan 2020 16:10 +00:00:
> Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > On 2019-12-23 06:35:08 +0000, Daniel Shahaf wrote:
> > > Vincent Lefevre wrote on Mon, 23 Dec 2019 02:21 +00:00:
> > > > On 2019-12-21 08:09:46 +0000, Daniel Shahaf wrote:
> > > > > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > > > > There's something wrong with "svn list -v" column alignment when
> > > > > > there are author names with more than 8 characters. For instance,
> > > > > > with the gcc repository:
> > > > > >
> > > > > > [...]
> > > > > > 279442 jozefl Dec 16 12:02 libgcc/
> > > > > > 278886 jvdelisle Dec 01 23:29 libgfortran/
> > > > > > [...]
> > > > >
> > > > > As implemented, the width is initially 8 but as soon as a longer name is seen,
> > > > > subsequent lines will be aligned with that, up to a maximum length of 16.
> > > > >
> > > > > Do you have a better algorithm to propose?
> > > >
> > > > cache the maximum length name in the working-copy data.
> > >
> > > Let's see. We could cache the value in wc.db. Running 'ls' or 'blame' [the
> > > same considerations apply to both] would update the cache; running 'cleanup'
> > > would purge it.
> > >
> > > Two things are not immediately clear to me:
> > >
> > > - This info is only needed by the cmdline client, not by other
> > > library users. This suggests the API should be generic. A
> > > per-client cache, maybe? There's already a
> > > svn_client_ctx_t::client_name so it's not unprecedented.
> >
> > Well, you don't know what the library users will do. Perhaps the cache
> > will benefit them too. The value can be used by them or not.
>
> I think you've missed my point. I'm saying we should try to design the cache
> API in a way that will allow it to be used not only for 'svn ls -v' but also
> for other things. The API does not exist to serve the cmdline client; it
> exists to serve _all_ svn clients.

To clarify: I think we should try to design the API in a way that will
(1) let it be used not only for author names but also for other things,
(2) let it be used not only by the cmdline client.

I mean, we _could_ add a private API that does "SELECT change_author
FROM nodes ORDER BY strlen(change_author) DESC LIMIT 1" and have the
cmdline client use that, and maybe that's actually the right answer, but
let's at least _try_ to come up with a better / more generic design first.

Cheers,

Daniel
Received on 2020-01-07 18:25:14 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.