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 <vinc...@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)
