subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <>
Subject Re: #4754: Status Cache
Date Mon, 25 Jun 2018 11:54:57 GMT
On Mon, Jun 25, 2018 at 01:44:21PM +0200, Branko ─îibej wrote:
> On 25.06.2018 13:37, Stefan Sperling wrote:
> > On Mon, Jun 25, 2018 at 01:29:04PM +0200, Branko ─îibej wrote:
> >> On 25.06.2018 13:21, Julian Foad wrote:
> >>> 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?
> >> Basically, sure. In practice, though, I've never found these
> >> notification services to be very reliable and consistent. All of them
> >> tend to leak events in one way or another. It's OK to have 95%
> >> correctness for painting icons in a GUI, but not OK for "svn status",
> >> let alone "svn commit".
> >>
> >> (I'd tend to be slightly miffed if a GUI told me I can't commit just
> >> after I changed a file ...)
> >>
> >> -- Brane
> >>
> > Why would the commit code have to rely on this feature?
> >
> > As I understand this proposal, the feature would be designed as a "fast"
> > replacement for svn_wc_walk_status(), for informational purposes only.
> >
> > The commit operation should keep working as it does today.
> You're missing my point a bit, so here it is framed more explicitly:
> Even if we have such a feature, we should tell users very loudly that
> the results are approximate, not exact. Obviously "svn commit" should
> not rely on such approximate information; and as far as I'm concerned,
> neither should "svn status" on the command line (or an explicit "show
> status" operation in a GUI, though of course we'd have no control over
> how that's implemented).

Yes, point taken. Though inaccuracy of information provided by status
services used could be considered a bug at their end.

In any case, we agree that this feature would need to take into account
any of the (non-)guarantees made by the underlying services.

I'll add that similar features have been written for other version
control systems, e.g. for Mercurial, and not without problems:
"""We solved this by monitoring the file system for changes. This has been
tried before, even for Mercurial, but making it work reliably is surprisingly

View raw message