Project Monitor: Changing the URL does not always work

[Andreas Grob]

Dear TortoisSVN team

My company moved all SVN repos to a new server and updated them.
A relocate for all local directories became necessary. In the project monitor I also changed the new URL and the authentication.
Unfortunately this did not work in all cases. However, deleting and recreating worked.
I could now reproduce this again by changing a URL (a '2' added) and setting it back again.
In the temporary file the following is written (abbreviated):

[item_017]
lastErrorMsg=<<SI-END-OF-MULTILINE-TEXT
Unable to connect to a repository at URL
 'https://svn.abc2.dev/svn/dev/projects/dummy/trunk'
The specified host is unknown.  
SI-END-OF-MULTILINE-TEXT
root=https://svn.abc.dev/svn/dev
wcPathOrUrl=https://svn.abc.dev/svn/dev/projects/dummy/trunk

My guess is that it has to do with the fact that wcPathOrUrl is much longer than the root path. So not just "/trunk" after it.

Greetings
~ Andreas

[Daniel Sahlberg]

Hi,

The URL is stored in wcPathOrUrl, and if I understand your description this is now correct.

The highlighted "2" is just part of the error message from the last time Project Monitor tried to check that project.

I would argue that Project Monitor actually succeeds in changing the URL, however it doesn't always clear the last error message. To be more precise, it clears the last error message the next time it finds a new commit in that repository. So if you had only waited a while, most error messages (and error icons) would have cleared themselves.

That being said, it is obviously not a good idea to keep an old error message. I've fixed this in the current /trunk, you should be able to check a new nightly build in a few hours. (Note that the nightly builds don't support the Windows 11 context menu yet, for this you'd have to wait for a new release).

For more details, check the tortoise-dev group or the source code.

Kind regards,

Daniel

[Andreas Grob]

Hi Daniel

Thank you for this solution. Always nice for a developer to see how a small change can make a big difference.

My subject probably obscures the real cause, but I think my MonitoringData snippet was able to give a hint. Also, for the other thread.

I have installed the nightly build r29490 and tested it. The first impression was good (all exclamation marks disappeared). But the solution is not completely clean.

If the URL is incorrect, the exclamation mark appears after "Check Now". When the erroneous entry is selected, it disappears again until the next "Check Now". However, in the right window you can always see the concrete error message, which differs if the hostname or the path of the URL is wrong.

If it is worth to work on it again, is not up to me. The current solution is better in any case.

Greetings
~ Andreas

[Daniel Sahlberg]

tisdag 6 december 2022 kl. 10:39:12 UTC+1 skrev Andreas Grob:

Hi Daniel

Thank you for this solution. Always nice for a developer to see how a small change can make a big difference.

My subject probably obscures the real cause, but I think my MonitoringData snippet was able to give a hint. Also, for the other thread.

I have installed the nightly build r29490 and tested it. The first impression was good (all exclamation marks disappeared). But the solution is not completely clean.

If the URL is incorrect, the exclamation mark appears after "Check Now". When the erroneous entry is selected, it disappears again until the next "Check Now". However, in the right window you can always see the concrete error message, which differs if the hostname or the path of the URL is wrong.

I believe you are seeing another issue. The code is checking for "latest revision" and this check seems to succeed even when the URL is not correct (this code is in SVN.cpp, GetHeadRevision). When the "latest revision" is equal to what has previously been fetched, the code doesn't try to fetch the log and therefore doesn't set the error message. I've posted a proposed solution in the -dev group and wait for some reply before committing.

Kind regards,

Daniel

[Andreas Grob]

Yes, this issue is only indirectly related.
You were already busy again. I just tested the nightly r29503. Unfortunately, the problem does not seem to be fundamentally fixed yet. As soon as I click on a project that has an exclamation mark because the path is invalid (forbidden in my case), it disappears. Only with "Check Now" or the new "Check project now" (very nice!) it appears again.

Just noticed (svn 1.14/1.15):
File name: TortoiseSVN-1.14.99.29503-dev-x64-svn-1.14.dev.msi
Version Information:
- TortoiseSVN 1.14.99, Build 29503 - 64 bit -dev, 2022/12/15 21:35:33
- Subversion 1.15.0, -dev

Greetings
~ Andreas

[Daniel Sahlberg]

fredag 16 december 2022 kl. 10:20:36 UTC+1 skrev Andreas Grob:

Yes, this issue is only indirectly related.
You were already busy again. I just tested the nightly r29503. Unfortunately, the problem does not seem to be fundamentally fixed yet. As soon as I click on a project that has an exclamation mark because the path is invalid (forbidden in my case), it disappears. Only with "Check Now" or the new "Check project now" (very nice!) it appears again.

Thanks for testing!

I had a separate fix for this which I didn't commit. It had a side effect of actually ADDING the exclamation mark on one of my test projects while still displaying the log. I think the log was fetched from the log cache but I didn't have time to reproduce it properly and thus held back in committing that fix. I will take another look.

 

Just noticed (svn 1.14/1.15):
File name: TortoiseSVN-1.14.99.29503-dev-x64-svn-1.14.dev.msi
Version Information:
- TortoiseSVN 1.14.99, Build 29503 - 64 bit -dev, 2022/12/15 21:35:33
- Subversion 1.15.0, -dev

Please be aware that the nightly builds, starting from yesterday, is based on Subversion /trunk and not the Subversion 1.14.x branch. This means it includes a new working copy format, including an option to not store "pristines". It should be counted as experimental until Subversion 1.15.0 is released.

Kind regards,

Daniel

[Stefan]

On Friday, December 16, 2022 at 11:05:42 AM UTC+1 daniel.l...@gmail.com wrote:

fredag 16 december 2022 kl. 10:20:36 UTC+1 skrev Andreas Grob:

Yes, this issue is only indirectly related.
You were already busy again. I just tested the nightly r29503. Unfortunately, the problem does not seem to be fundamentally fixed yet. As soon as I click on a project that has an exclamation mark because the path is invalid (forbidden in my case), it disappears. Only with "Check Now" or the new "Check project now" (very nice!) it appears again.

Thanks for testing!

I had a separate fix for this which I didn't commit. It had a side effect of actually ADDING the exclamation mark on one of my test projects while still displaying the log. I think the log was fetched from the log cache but I didn't have time to reproduce it properly and thus held back in committing that fix. I will take another look.

 

When you take another look, also please consider that retrying in case of an authentication/authorization error should be avoided. Because this could easily lead to locked accounts.

Stefan

[Daniel Sahlberg]

Good point, thank you!

I have made a change today and it seems more consistent in my testing. The problem was the code setting the overlay sometimes considered the "lastError" and sometimes not.

Kind regards,

Daniel