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

[Robert Gruber]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdev_34_cvs_part2.patch
Type: text/x-diff
Size: 3283 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070504/ddac84f0/attachment.bin>