On 2020-01-13 16:51:25 +0000, Daniel Shahaf wrote: > Vincent Lefevre wrote on Mon, 13 Jan 2020 10:26 +00:00: > > Good point. I was about to say that in most cases, these commands are > > run from a working copy. But I now think that caching should be done > > under the user's home (just like with most applications). Under Unix, > > this would be under "$XDG_CACHE_HOME/subversion". > > When would data be evicted from the cache?
In this particular case, I wonder whether there is any reason to evict data from the cache. And the user can still entirely remove the cache manually if need be. > I'd say UUID, but we don't have to decide this now. On 2020-01-14 13:19:08 +0100, Branko Čibej wrote: > Why are we overthinking this? This information is really not relevant > for integration with other tools: > > * GUIs don't need it; they can always dynamically resize columns in forms. Dynamic resize is annoying: one is reading something, but this suddenly goes away due to a resize. > * The command-line doesn't (really) need it; all information, > including untruncated commiter names, is available in --xml mode. Yes, but this needs to add a pipe or use a different command name (this is no way to override the "svn ls" behavior... except by using a wrapper, attempting to parse the arguments). BTW, if untruncated committer names are available in --xml mode, it was not necessary to change the behavior and break the column alignment. > Adding a layer of caching is only going to add a stale-cache problem > that we don't have now. What stale-cache problem? -- 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)
