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. > In any case, making the information available will not hurt. It will hurt, actually. If we add the API we'll need to support it until 2.0 (= indefinitely), and everyone who ever tried to write code to the libsvn_client interface will have another function docstring to read and decide they don't care about. > > - What the cache keys should be. wc.db is designed to be shared > > among multiple WC's, so presumably the cache should be per-wcroot > > or possibly per-repository? > > I don't understand. The wc.db file is inside the .svn directory of > the WC. How can it be shared by multiple WC's? It isn't, yet. I only said it was "_designed_ to be shared among multiple WC's". The SQL schema is designed to allow a single wc.db to reside in, say, $HOME/wc.db and be shared by multiple working copies: for example, in the schema working copy files are identified by a (wc_id, local_relpath) pair. We never got around to actually making multiple working copies share a wc.db, but the low-level support is already there.
