KDev3 SVNFileInfoPovider::status

Hi,

the status() function in SVNFileInfoProvider is synchronous
and is
dead-slow on large trees (like kdelibs). Also its called (as
far as I
can tell) for each click on a directory in the file tree
view runs
status() on the directory.

So, can somebody please make this async, or at least make
sure the
svn-call doesn't recurse into subdirectories as obviously
thats not
needed for the filetree view.

Andreas

-- 
A tall, dark stranger will have more fun than you.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/4/18, Andreas Pakulat <apakugmx.de>:
> the status() function in SVNFileInfoProvider is
synchronous and is
> dead-slow on large trees (like kdelibs). Also its
called (as far as I
> can tell) for each click on a directory in the file
tree view runs
> status() on the directory.
>
> So, can somebody please make this async,

I tried once to make it async, but it was some deep kdelibs
routines that creates the of each item on filetreeview. So
I couldn't touch the underlying mechanism.

> or at least make sure the
> svn-call doesn't recurse into subdirectories as
obviously thats not
> needed for the filetree view.

I committed this fix.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/4/18, Andreas Pakulat <apakugmx.de>:
> the status() function in SVNFileInfoProvider is
synchronous and is
> dead-slow on large trees (like kdelibs). Also its
called (as far as I
> can tell) for each click on a directory in the file
tree view runs
> status() on the directory.
>
> So, can somebody please make this async,

I tried once to make it async, but it was some deep kdelibs
routines that creates the of each item on filetreeview. So
I couldn't touch the underlying mechanism.

> or at least make sure the
> svn-call doesn't recurse into subdirectories as
obviously thats not
> needed for the filetree view.

I committed this fix.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 18.04.07 14:44:54, dukju ahn wrote:
> 2007/4/18, Andreas Pakulat <apakugmx.de>:
> > the status() function in SVNFileInfoProvider is
synchronous and is
> > dead-slow on large trees (like kdelibs). Also its
called (as far as I
> > can tell) for each click on a directory in the
file tree view runs
> > status() on the directory.
> >
> > So, can somebody please make this async,
> 
> I tried once to make it async, but it was some deep
kdelibs
> routines that creates the of each item on filetreeview.
So
> I couldn't touch the underlying mechanism.

Yeah, thats why I gave up too...

> > or at least make sure the
> > svn-call doesn't recurse into subdirectories as
obviously thats not
> > needed for the filetree view.
> 
> I committed this fix.

Unfortunately that breaks the status display. I'm not sure
what the
reason for that is, but the top-level dirs inside the
project are not
colored and don't have status information associated.
However opening
one of the items does show status for its childs.

Andreas

-- 
You will be imprisoned for contributing your time and skill
to a bank robbery.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> > > or at least make sure the
> > > svn-call doesn't recurse into subdirectories
as obviously thats not
> > > needed for the filetree view.
> >
> > I committed this fix.
>
> Unfortunately that breaks the status display. I'm not
sure what the
> reason for that is, but the top-level dirs inside the
project are not
> colored and don't have status information associated.
However opening
> one of the items does show status for its childs.

You are partly true, but the problem that toplevel status
information
is not displayed at project openning had existed since the
recent
few weeks. In other word, it is not the nonrecurse fix that
caused
status display bug.

Anyway, I think I should work on this before the KDE 3.5.7
tagging.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> > > or at least make sure the
> > > svn-call doesn't recurse into subdirectories
as obviously thats not
> > > needed for the filetree view.
> >
> > I committed this fix.
>
> Unfortunately that breaks the status display. I'm not
sure what the
> reason for that is, but the top-level dirs inside the
project are not
> colored and don't have status information associated.
However opening
> one of the items does show status for its childs.

You are partly true, but the problem that toplevel status
information
is not displayed at project openning had existed since the
recent
few weeks. In other word, it is not the nonrecurse fix that
caused
status display bug.

Anyway, I think I should work on this before the KDE 3.5.7
tagging.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 18.04.07 15:35:17, dukju ahn wrote:
> > > > or at least make sure the
> > > > svn-call doesn't recurse into
subdirectories as obviously thats not
> > > > needed for the filetree view.
> > >
> > > I committed this fix.
> >
> > Unfortunately that breaks the status display. I'm
not sure what the
> > reason for that is, but the top-level dirs inside
the project are not
> > colored and don't have status information
associated. However opening
> > one of the items does show status for its childs.
> 
> You are partly true, but the problem that toplevel
status information
> is not displayed at project openning had existed since
the recent
> few weeks. In other word, it is not the nonrecurse fix
that caused
> status display bug.
> 
> Anyway, I think I should work on this before the KDE
3.5.7 tagging.

Yes, that would be good.

BTW: If this gets working again I might switch back to
integrated svn
support. Which basically means: Big thanks to you for your
work on this.

Andreas

-- 
Of course you have a purpose -- to find a purpose.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/4/18, Andreas Pakulat <apakugmx.de>:
> Unfortunately that breaks the status display. I'm not
sure what the
> reason for that is, but the top-level dirs inside the
project are not
> colored and don't have status information associated.
However opening
> one of the items does show status for its childs.

I've fount the possible reason for this bug, but I can't
fix.
I need help.

The reason was that KIO::NetAccess::synchronousRun() used
in
SVNFileInfoProvider::status()
returns immediately before the job actually finishes.
Thus the returned VCSFileInfoMap is empty. So the top-level
dir are not colored when we firstly open the project.

Then what caused the NetAccess::synchronousRun() returns
immediatly??

First see the attached logfile.
See line 197. synchronousRun() about to be started.
But right after BlockingProcess calls exit_loop().
And see line 205. synchronousRun() finishes __right after__
the
BlockingKProcess calls exit_loop()
And see line 208. the kio_svnProtocol starts to run now.
Then see line 242. The BlockingKProcess exits from its loop,
with timeout.
This BlockingKProcess instance was created in line 165.

Note that NetAccess::synchronousRun() also uses the same
qApp->enter_loop(), exit_loop() to implement blocking.

In my machine, when I open the project my UI always blocks
for exactly one minitues. I think some buggy interaction
between
BlockingKProcess and synchronousRun() is the reason for both
bug.

-- that is, blocking UI for one minitues after opening the
project
  and the initial VCS status is not colored in
filetreeview.

I need help. And this should be resolved before the 3.5.7
tag.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/4/18, Andreas Pakulat <apakugmx.de>:
> Unfortunately that breaks the status display. I'm not
sure what the
> reason for that is, but the top-level dirs inside the
project are not
> colored and don't have status information associated.
However opening
> one of the items does show status for its childs.

I've fount the possible reason for this bug, but I can't
fix.
I need help.

The reason was that KIO::NetAccess::synchronousRun() used
in
SVNFileInfoProvider::status()
returns immediately before the job actually finishes.
Thus the returned VCSFileInfoMap is empty. So the top-level
dir are not colored when we firstly open the project.

Then what caused the NetAccess::synchronousRun() returns
immediatly??

First see the attached logfile.
See line 197. synchronousRun() about to be started.
But right after BlockingProcess calls exit_loop().
And see line 205. synchronousRun() finishes __right after__
the
BlockingKProcess calls exit_loop()
And see line 208. the kio_svnProtocol starts to run now.
Then see line 242. The BlockingKProcess exits from its loop,
with timeout.
This BlockingKProcess instance was created in line 165.

Note that NetAccess::synchronousRun() also uses the same
qApp->enter_loop(), exit_loop() to implement blocking.

In my machine, when I open the project my UI always blocks
for exactly one minitues. I think some buggy interaction
between
BlockingKProcess and synchronousRun() is the reason for both
bug.

-- that is, blocking UI for one minitues after opening the
project
  and the initial VCS status is not colored in
filetreeview.

I need help. And this should be resolved before the 3.5.7
tag.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 20.04.07 09:37:39, dukju ahn wrote:
> 2007/4/18, Andreas Pakulat <apakugmx.de>:
> Then what caused the NetAccess::synchronousRun()
returns immediatly??
> 
> First see the attached logfile.
> See line 197. synchronousRun() about to be started.
> But right after BlockingProcess calls exit_loop().
> And see line 205. synchronousRun() finishes __right
after__ the
> BlockingKProcess calls exit_loop()
> And see line 208. the kio_svnProtocol starts to run
now.
> Then see line 242. The BlockingKProcess exits from its
loop, with timeout.
> This BlockingKProcess instance was created in line
165.
> 
> Note that NetAccess::synchronousRun() also uses the
same
> qApp->enter_loop(), exit_loop() to implement
blocking.

Ok, this is going to be a problem. We can't solve this,
except removing
BlockingKProcess, which will cause severe other problems
(like broken
QMake Manager). Except if Andras sees a way to make this
work (he wrote
BlockingKProcess).

I think we should rather look again into making it
asynchronously. I'll
try to have a look this weekend, but I can't promise
anything (my
grandmother is celebrating 70th birthday tomorrow) so if
somebody else
has the time please don't hesitate.

> -- that is, blocking UI for one minitues after opening
the project
>  and the initial VCS status is not colored in
filetreeview.
> 
> I need help. And this should be resolved before the
3.5.7 tag.

Well, thats still 10 days away and even if we don't make it
thats not a
severe problem. After all its just the top-level dirs.

Andreas

-- 
You will have domestic happiness and faithful friends.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel