subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: #4754: Status Cache
Date Mon, 25 Jun 2018 11:33:54 GMT
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.

Mime
View raw message