D7995: KDevelop: address dirwatching inefficiency (WIP/PoC)

[René J.V. Bertin]

rjvbb added a comment.


  But under what circumstances does `it adds a new folder or file item when none exists`? Or rather, under what circumstances is that not being taken care of by the eventuallyReadFolder method? If the AbstractFileManagerPlugin creates new folders or files itself, why add them to the project view indirectly via the dirwatcher?
  
  Is there a sequence of operations I can try in an actual session that you think should fail without that block of code (= in my current builds)?
  
  (I assume you also re-read the KDirWatch doc?)
  
  > I honestly cannot understand your reasoning though. If you want to help out with KDevelop development, you have to target master.
  
  I hope then that this is still small enough to make 5.2.1 . I don't just help out with KDevelop development, I use it, and the master branch has too often been breaking things for me. There's no problem as long as I don't have to maintain 2 very different versions of the same patch.
  
  What about the direct commit of the restartDirScan() check, can that one be merged immediately into 5.2 (or committed there too)?
  
  >   auto watcher = m_watchers.value(folder->project());
  
  I've been meaning to ask, what's the advantage of using auto here? I find it doesn't help reading the code and it feels like going back to the sloppy-typed days of good ole C.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D7995

To: rjvbb, #kdevelop, mwolff
Cc: arrowdodger, kfunk, dfaure, mwolff, brauch, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170927/e54df0a5/attachment.html>