From kdevelop-devel  Thu May 03 15:15:38 2007
From: Robert Gruber <rgruber () users ! sourceforge ! net>
Date: Thu, 03 May 2007 15:15:38 +0000
To: kdevelop-devel
Subject: [Patch] Bugs in KDev-3.4's cvs part
Message-Id: <200705031715.38827.rgruber () users ! sourceforge ! net>
X-MARC-Message: https://marc.info/?l=kdevelop-devel&m=117821600101819
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--Boundary-00=_ayfOGx7b8RgiE2a"

--Boundary-00=_ayfOGx7b8RgiE2a
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi!

When I updated my kdevelop-3.4 today (didn't update for the last month or so)  
to the most recent revision from "branches/KDE/3.5/kdevelop" I recognized 
some bugs in the cvs-part (from which unfortunatly I can only fix two out of 
three).

(1)
Whenever I open a project which uses the CVS part, a messagebox pops up 
telling my, that no working directory has been specified. 
I traced this back to the filetree. It tries up update the status infos for 
it's files when a new project gets opened. The problem here is, that the 
filetree reacts on the projectOpened() signal before the cvs-part, which 
therefore does not know on which directory he should issue the "cvs status" 
command.
Is there any change to make cvspart get setup before other parts?



(2)
Updateing the VCS infos in the filetree takes very long even if a directory 
only contains a few files.
Dukju added two addidional parameters to he 
CVSFileInfoProvider::requestStatus() method. The first parameter (bool 
recursive) is ok, but the second one (bool checkRepos) IMHO make no sense at 
least not as it is implemented now. It get's passed as third parameter 
(called "taginfo") to CvsService_stub::status() which will make "cvs status" 
print all tags for every single file. 
Before Dukju's change this taginfo parameter was set fixed false. Now it's 
true which will make cvs print out a lot more unneeded information for every 
single file. Next to the fact that the information is unneeded, the parser is 
also unable to handle that ouput and therefore tries to reinsert the same 
fileinfo again and again. So the whole thing got pretty slow.
To fix this I just ignore the "bool checkRepos" parameter and set the taginfo 
to false (as it was before). See patch file.



(3)
I think I've found a bug in the cvs client. It happened to me, that the client 
produced no ouput if called onto a directory with a tailing slash.
This one works:
cvs status -l 'somedir'
While this one doesn't:
cvs status -l 'somedir/'

So I added a check which will ensure that we always pass correct paths to the 
cvs client. See patch file.


Please review and tell me if commiting it is ok.
Greets, Robert

--Boundary-00=_ayfOGx7b8RgiE2a
Content-Type: text/x-diff;
  charset="us-ascii";
  name="kdev_34_cvs.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="kdev_34_cvs.patch"

Index: cvsfileinfoprovider.cpp
===================================================================
--- cvsfileinfoprovider.cpp	(revision 660601)
+++ cvsfileinfoprovider.cpp	(working copy)
@@ -81,9 +81,16 @@
         m_previousDirPath = dirPath;
     }
 
+    // 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;

--Boundary-00=_ayfOGx7b8RgiE2a
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--Boundary-00=_ayfOGx7b8RgiE2a--