On Jun 25, 2018, at 7:21 AM, Julian Foad <julianfoad_at_apache.org> wrote:
>
> I just filed https://issues.apache.org/jira/browse/SVN-4754 with this description:
>
> [[[
> Core svn should provide a way to cache WC status results, so clients can get a quick answer to questions like "is the WC modified?"
>
> Finding the WC status (local modifications) in core svn currently requires crawling the selected subtree in the filesystem to check the modification dates and sizes of all files, to see whether any files are modified. The API is svn_wc_walk_status().
>
> Subversion GUI clients like Cornerstone and TortoiseSVN want to know instantly whether a given directory contains any local modifications, in order to grey-out or hide buttons like "Shelve" and "Commit" and "Revert" and/or to show status icons. TortoiseSVN implements its own status cache for this reason. Cornerstone does not yet, and would like to offer an instant visual status indication.
>
> A status cache could be updated by integrating with a filesystem "watching" service where one is available (FSEvents API on Mac, inotify on Linux, etc.), or by (more or less continuous) background scanning.
>
> The command-line client should be able to benefit from such a cache as well, if built with an appropriate watching or scanning module.
>
> It's a really old problem. I was surprised I could not find an existing issue, except for https://issues.apache.org/jira/browse/SVN-3038 "caching out-of-date (remotely modified) status" which is a subset or extension of the basic issue (and was closed due to lack of understanding, from lack of appropriate discussion, in my opinion).
> ]]]
>
> Can someone confirm this makes sense as a feature request?
>
> I know the usual caveats apply: details need to be filled in, and lack of resources; but basically?
The problem is real. I do not see how it makes sense for Subversion to try to solve it though. How can the command line client ever rely on the presence of an external daemon and that it has been running and doing its job as needed? I do not know the state of this feature in TortoiseSVN, but I recall it had its difficulties over the years in terms of dealing with edge cases and problems.
Lack of resources aside, we could obviously implement such a daemon and feature but explain to me how the command line client could ever trust it? Maybe it is easier than I imagine and I just need to see a proposal but it seems out of scope for this project IMO.
Mark
Received on 2018-06-25 13:31:42 CEST