[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    [Patch] Bugs in KDev-3.4's cvs-part (Part 2)
From:       Robert Gruber <rgruber () users ! sourceforge ! net>
Date:       2007-05-04 9:23:04
Message-ID: 200705041123.04232.rgruber () users ! sourceforge ! net
[Download RAW message or body]

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

["kdev_34_cvs_part2.patch" (text/x-diff)]

Index: cvsfileinfoprovider.h
===================================================================
--- cvsfileinfoprovider.h	(revision 660601)
+++ cvsfileinfoprovider.h	(working copy)
@@ -43,6 +43,8 @@
 
 public slots:
     void updateStatusFor( const CVSDir& );
+private slots:
+    void propagateUpdate();
 
 signals:
     void needStatusUpdate(const CVSDir&);
Index: cvsfileinfoprovider.cpp
===================================================================
--- cvsfileinfoprovider.cpp	(revision 660601)
+++ cvsfileinfoprovider.cpp	(working copy)
@@ -10,6 +10,7 @@
  ***************************************************************************/
 
 #include <qregexp.h>
+#include <qtimer.h>
 #include <kurl.h>
 #include <kdebug.h>
 
@@ -82,8 +83,30 @@
     }
 
 
+    if (!checkRepos) {
+        kdDebug(9006) << "No repo check reqested; Just read CVS/Entries from: " << dirPath << endl;
+        QDir qd(projectDirectory()+QDir::separator()+dirPath);
+        CVSDir cdir(qd);
+        if (cdir.isValid())
+        {
+            emit needStatusUpdate(cdir);
+            return true;
+        }
+        kdDebug(9006) << dirPath << " is not a valid cvs directory" << endl;
+        return false;
+    }
+
+    // Fix a possible bug in cvs client:
+    // When "cvs status" get's called nonrecursiv for a directory, it will
+    // not print anything if the path ends with a slash. So we need to ensure
+    // this here.
+    QString newPath = dirPath;
+    if (newPath.endsWith("/"))
+        newPath.truncate( newPath.length()-1 );
+
+
     // path, recursive, tagInfo: hmmm ... we may use tagInfo for collecting file tags ...
-    DCOPRef job = m_cvsService->status( dirPath, recursive, checkRepos );
+    DCOPRef job = m_cvsService->status( newPath, recursive, false );
     m_requestStatusJob = new CvsJob_stub( job.app(), job.obj() );
 
     kdDebug(9006) << "Running command : " << m_requestStatusJob->cvsCommand() << endl;
@@ -101,10 +124,29 @@
     }*/
 }
 
+void CVSFileInfoProvider::propagateUpdate()
+{
+    emit statusReady( *m_cachedDirEntries, m_savedCallerData );
+}
+
 void CVSFileInfoProvider::updateStatusFor(const CVSDir& dir)
 {
     m_cachedDirEntries = dir.cacheableDirStatus();
-    emit statusReady( *m_cachedDirEntries, m_savedCallerData );
+    printOutFileInfoMap( *m_cachedDirEntries );
+
+    /* FileTree will call requestStatus() everytime the user expands a directory
+     * Unfortunatly requestStatus() will be called before the 
+     * VCSFileTreeViewItem of the directory will be filled with the files
+     * it contains. Meaning, m_savedCallerData contains no childs at that
+     * time. When a dcop call is made to run "cvs status" this is no problem.
+     * The dcop call takes quit long, and so FileTree has enough time the fill
+     * in the childs before we report the status back.
+     * As far as the reading of the CVS/Entries file is very fast, 
+     * it will happen that we emit statusReady() here before the directory 
+     * item conains any childs. Therefor we need to give FileTree some time
+     * to update the directory item before we give the status infos.
+     */
+    QTimer::singleShot( 1000, this, SLOT(propagateUpdate()) );
 }
 
 ///////////////////////////////////////////////////////////////////////////////


_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel


[prev in list] [next in list] [prev in thread] [next in thread]