[Patch] Bugs in KDev-3.4's cvs-part (Part 2)

[Matt Rogers]

On Friday 04 May 2007 04:23, Robert Gruber wrote:
> Hi!
>
> The patch for CvsFileInfoProvider I sent yesterday has some shortcomings.
> As I ignored the "bool checkRepos" parameter, everytime the user expands a
> directory, the cvs server get queried. This would lead to heavy traffic to
> the cvs server if someone does a lot of directory switching. So I though
> it might be better to read the status from the CVS/Entries file if
> checkRepos is set to false. And just query the cvs server if the user
> explicitly requests a status update (checkRepos==true).
>
> But while implementing the read from the local CVS/Entries file I ran
> into another problem. The FileTree part requests the status everytime
> the expanded() signal of a directory-item is executed. When the directory
> is expanded for the first time, the directory-item does not contain any
> childs at the time the CvsFileInfoProvider gets called. The childs seam
> to be created async (but I wasn't able to find out how). The reading from
> CVS/Entries file is so damned fast, that the CvsFileInfoProvider sends
> the status back to the FileTree even before it has added the childs to
> the directory-item. No problem here when calling "cvs status". The
> dcop call is pretty slow so it seams there is enough time for FileTree
> to create the childs.
> So in the slot VCSFileTreeWidgetImpl::vcsDirStatusReady() no childs will
> be found for the directory-item and the FileTree will therefore ignore the
> status that has been reported by the CvsFileInfoProvider. When I then
> close and re-expand the directory-item, the status-update works
> because the childs have been created in the previous run.
>
> I found no other solution than holding back the statusReady() signal a
> bit using QTimer::singleShot(1000,...). But this looks quit ugly to me.
> Hopefully anybody has a better solution?
>
> Nevertheless I've attached the patch...
>
>
> Robert

This is the best we can do for now. Please commit.
-- 
Matt