Hi Daniel,
The problem is also reproducible with svn CLI tools apart from TortoiseSvn: When I clone a working copy into a "Windows" drive (e.g. C:\path_to_working_copy), I can only access it from svn tools running in Windows. If I operature on this working copy from a WSL svn utility (via going to /mnt/c/path_to_working_copy), I get following error:
svn: E200030: sqlite[S10]: disk I/O error
svn: E200042: Additional errors:
svn: E200030: sqlite[S10]: disk I/O error
svn: E200044: SQLite transaction rollback failed
svn: E200030: sqlite[S1]: cannot rollback - no transaction is active
svn: E200030: sqlite[S1]: cannot rollback - no transaction is active
When I clone a working copy into a "WSL" drive (e.g. /home/user/path_to_working_copy), I can only access the working copy with svn tools running in WSL (linux). If I operate on this working copy from a Windows svn utility (powershell via \\wsl.localhost\ubuntu\home\user\path_to_workking_copy) I get following error message:
svn: E200033: Another process is blocking the working copy database, or the underlying filesystem does not support file locking; if the working copy is on a network filesystem, make sure file locking has been enabled on the file server
svn: E200033: sqlite[S5]: database is locked, executing statement 'PRAGMA case_sensitive_like=1;PRAGMA synchronous=OFF;PRAGMA recursive_triggers=ON;PRAGMA foreign_keys=OFF;PRAGMA locking_mode = NORMAL;PRAGMA journal_mode = TRUNCATE;'
If I copy a working copy from its Windows drive (e.g. C:\path_to_working_copy) to a a WSL drive (e.g. /home/user/wc_copy), I can operate on the copy with the Linux tools but not anymore with the Windows tools.
This implies that the Linux svn tools (or internally SQLite) can only work with working copies that are located on Linux drives. And that Windows svn tools can only operate on working copies that are located on Windows drives.
The EOL differences do not matter for this issue.
To workaround the issue, TortoiseSvn can perhaps interact with the Linux svn tools in WSL when it detects that the working copy location is a WSL or Linux drive.
Or are other workarounds possible?
Johan