On Mon, Jun 25, 2018 at 12:21:03PM +0100, Julian Foad 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?
Yes, it does.
I would suggest to focus on platform-specific filesystem status services only.
The current status walk can be used where those services aren't available.
I don't think a background scanning walk inside our library makes sense
because it can be trivially implemented by the API user -- just run
svn_wc_walk_status() in a separate thread.
Given that this is targeting GUI clients mostly, having status cache
implementations for Windows and Mac would probably suffice.
This feature should not repeat the mistake made in the svn_auth API
where we expose platform-specific functions as part of public API.
The public API for this feature must be platform-independent.
If the feature isn't available on the run-time platform, the API should
indicate so by returning a specific error code from all entry points.
The API should also provide a function which returns TRUE/FALSE to indicate
whether the feature is available at run-time.
Received on 2018-06-25 13:34:04 CEST