Bug: SlickEdit does not show SVN file status on file icon

[pieterc]

Hi everyone!

I created a local SVN repository and a SlickEdit test project containing one file that has been changed. SlickEdit does not indicate with an overlay icon that the file has changed.

I am attaching the project (with SVN repository) and a screenshot that illustrates my SVN settings.

Best regards,
Pieter

[Dan]

I'll take a look at it.

Can you send me the output from "svn info"?  There may be a parsing error of some sort.

[pieterc]

Hi Dan,

Here is the output:

C:\Temp\slickedit_svn_test\slickedit_project>svn info
Path: .
Working Copy Root Path: C:\Temp\slickedit_svn_test\slickedit_project
URL: file:///C:/Temp/slickedit_svn_test/svn_repo
Relative URL: ^/
Repository Root: file:///C:/Temp/slickedit_svn_test/svn_repo
Repository UUID: 1fec3b55-d1a8-be43-997d-a4a6d5542284
Revision: 1
Node Kind: directory
Schedule: normal
Last Changed Author: PieterC
Last Changed Rev: 1
Last Changed Date: 2017-09-12 11:13:32 +0200 (Tue, 12 Sep 2017)

[pieterc]

Hi Dan,

Here is the output when I run "svn status --xml":

C:\Temp\slickedit_svn_test\slickedit_project>svn status --xml
<?xml version="1.0" encoding="UTF-8"?>
<status>
<target
   path=".">
<entry
   path="slickedit_project.vpw">
<wc-status
   item="modified"
   revision="1"
   props="none">
<commit
   revision="1">
<author>PieterC</author>
<date>2017-09-12T09:13:32.626555Z</date>
</commit>
</wc-status>
</entry>
<entry
   path="slickedit_project.vpwhist">
<wc-status
   props="none"
   item="unversioned">
</wc-status>
</entry>
<entry
   path="slickedit_project.vtg">
<wc-status
   item="unversioned"
   props="none">
</wc-status>
</entry>
<entry
   path="test.txt">
<wc-status
   item="modified"
   revision="1"
   props="none">
<commit
   revision="1">
<author>PieterC</author>
<date>2017-09-12T09:13:32.626555Z</date>
</commit>
</wc-status>
</entry>
</target>
</status>

[jkwuc89]

I am seeing the same behavior with Git. I have Show status on file icons turned on under Tools | Version Control | Version Control Providers | Git and file icons are unchanged when changing a file under Git source control.

[jkwuc89]

After waiting a bit (I don't have the exact time duration), the file icon did change to indicate a changed file. And now, other file icons are almost immediately showing Git status updates.

[pieterc]

Hi Dan and jkwuc89,
I'm observing the same weird behavior. After reopening up the example project, the changed icon overlay mysteriously appeared. The example project uses a local (file:///) repository. I then went back and tried a project that uses a server repository (svn://), but the changed icon overlay does not appear, even after waiting for a long time.
When I right-click on a changed file and show the History dialog, it correctly reports "Status: Locally modified". There must be a background thread that is launched periodically to see if file status has changed. How can I verify that this thread is executed and what the results are? With a little bit of guidance, is it possible for me to debug Slick-C "subversion.e", or add debug print statements to narrow down the problem for you?

Regards,
Pieter

[Dan]

There is a thread that runs svn or git, and a timer that periodically checks to see if there is any new information from that thread.  The first thing you can do is change the time on the version control setup to 1 minute.  Next, you can bring up the Task Manager and see if svn or git is getting run.  If you save a file, it should be run almost immeidately, and normally you'll have a mark on the file icon almost instantly.

If you determine that it is not working at all, I can send you a DLL with some debug in it and you can send me the output and we'll see if there is some sort of parse error.  Sometimes, depending on how things get checked out, the filenames that get put back together (you can see from the XML there are not absolute paths returned) can be problematic.  I think I have figured out how to solve this now, but it may not have reached this/these piece(s) of code.

[pieterc]

Hi Dan,
Sorry for the late reply! It is hard to spot in the Task manager if an SVN thread is launched, because there are a LOT of background processes... by the time I've scrolled down, it has probably disappeared again 

Please send me the DLL with debug and I'll do the legwork for you.

Regards,
Pieter

[pieterc]

Hi Dan,
If I may be so bold as to suggest a new feature... maybe a green tick should be overlaid to show that the file is unchanged (the same way that TortoiseSVN works now). This gives positive feedback that the SVN checking thread is working and has returned a result.
Regards,
Pieter

[Dan]

Hi Dan,
If I may be so bold as to suggest a new feature... maybe a green tick should be overlaid to show that the file is unchanged (the same way that TortoiseSVN works now). This gives positive feedback that the SVN checking thread is working and has returned a result.
Regards,
Pieter

This is an interesting idea.

[Dan]

Hi Dan,
Sorry for the late reply! It is hard to spot in the Task manager if an SVN thread is launched, because there are a LOT of background processes... by the time I've scrolled down, it has probably disappeared again 

Please send me the DLL with debug and I'll do the legwork for you.

Regards,
Pieter

You can speed up the the task manager, that might help.

I'll happily send you a DLL, but I'll have to wait until at least after the release candidate goes out.  Also some of the work will be in filewatcher.e.

[pieterc]

Hi Dan,
I also tried SysInternals ProcMon to see if vs.exe launches another task every minute, but failed to see it (I'm not exactly sure what to look for ). All I can say for certain is that it's not working and I added another screenshot to demonstrate it.
I will wait until you are ready to send a debug DLL.
Best regards,
Pieter

[Dan]

With a little luck I'll send you something Monday and we'll get this sorted out.  Let us go ahead and get RC1 out, be sure it's relatively stable, and then I'll send you something.  I promise I'll do my best to sort it out, I put the feature in because I want it to work.  It is a tough one to debug remotely though.

[Dan]

OK... so, I'm thinking this through.  Both of you have it work, eventually, correct?  I'm wondering if some sort of timing tweak is what we need here.