On 25.06.2018 13:54, Stefan Sperling wrote:
> 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
> challenging."""
> https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
Heh heh, that also says:
"After much deliberation, we concluded that Git's internals would be
difficult to work with for an ambitious scaling project."
I wonder how long the author needed to come up with such a diplomatic
statement. :)
-- Brane
Received on 2018-06-25 14:19:05 CEST