On 2020-01-08 13:12:21 +0000, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Wed, Jan 08, 2020 at 10:28:01 +0100:
> > On 2020-01-07 16:10:52 +0000, Daniel Shahaf wrote:
> > > Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > > > On 2019-12-23 06:35:08 +0000, Daniel Shahaf wrote:
> > > > > 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.
> >
> > I entirely agree. But I'm still confused by your first sentence above
> > "This info is only needed by the cmdline client, not by other library
> > users." or perhaps you misplaced the "not"?
>
> The length of the longest author name is needed by 'svn ls -v'.
>
> The length of the longest author name is unlikely to be needed by
> other consumers of the svn_client_* API.
A reimplementation of "svn ls -v" or "svn blame" may find this useful
information. Graphical clients may be interested in a cached full list
of authors to compute the size of the corresponding column.
--
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-10 15:28:42 CET