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).
-- Brane
Received on 2018-06-25 13:44:31 CEST