Agreeing with the others who have responded that this is a problem in the TSVN code even though the assertion occurs in SVN code. The problem is that TSVN is trying to get data from the server (which is unreachable, and this is correctly reported form SVN) and it handles this error by setting the repository URL to an empty string instead of https://server.url/svn/repository. TSVN then tries to call the SVN api again with this empty string (plus the /trunk/whatever.file part) which causes the assertion.
I have reported this on the TSVN mailing lists: https://groups.google.com/g/tortoisesvn-dev/c/YkgDdoR7ef0 In my opinion TSVN should not even allow Show Changes in offline mode (since we need to get the old version (and new - if not the same as the one in WC) of the file from the server). This is a limitation of SVN compared to for example GIT where you have the complete repository locally. Kind regards, Daniel Den ons 18 nov. 2020 kl 00:15 skrev Dirk Helgemo <dirk.helg...@entrust.com>: > Repro = SVN checkout, make changes to a file, SVN commit, SVN log. Remove > access to the SVN server (mine is accessible only via VPN, so disconnect > VPN). Right-click a file, SVN Show Log, press Offline for now (not the > default), find the file modification in the path/action list. Then either > double-click on the file, or right-click on the file : Show Changes. The > result is as follows: > > > > Subversion Exception! > > Subversion encountered a serious problem. > > … > > In file > > > 'D:\Development\SVN\Releases\TortoiseSVN-1.11.0\ext\subversion\subversion\libsvn_wc\wc_db.c' > > line 10238: assertion failed (svn_dirent_is_absolute(local_abspath)) > > > > Pressing OK results in another pop-up: > > > > TortoiseSVN > > Subversion reported an error: > > 'C:\Users\<me>\AppData\Local\Temp\3' is not a working copy > > > > (My sandbox is in C:\_SVN, not C:\Users. Maybe Windows is virtualizing > storage for SVN? Maybe a check for server accessibility isn’t quite right?) > > > > The workaround is to reconnect to the server (reconnect the VPN in my > case), but I was surprised that SVN would crash when offline. > > > > Thanks in advance for your attention. -Dirk >
