Re: TortoiseSVN not working on folders of WSL2

[TortoiseSVN]

Hi Daniel,

I understand that adding such a service would be some work. However, do
please consider this because the original issue on WSL has been open for 3
years and nothing has happened.

Apart from the issue described above, we also suffer from the issue as
described in
https://stackoverflow.com/questions/72317768/right-click-in-windows-on-a-svn-folder-shared-in-wsl-takes-forever-why
Do you have any idea about that one?

Johan Laneau

-- 
You received this message because you are subscribed to the Google Groups 
"TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tortoisesvn+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tortoisesvn/CAN69bir5L5JO8YMqp-7BF41YRZvmJR6GxJOC6-0dDNS6FFNUzg%40mail.gmail.com.

Re: TortoiseSVN not working on folders of WSL2

[Daniel Sahlberg via TortoiseSVN]

torsdag 26 januari 2023 kl. 14:33:15 UTC+1 skrev johan@gmail.com:
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;'


Thanks for checking, too bad it didn't work out.
 
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.

Unfortunately this is probably related to the locking problems and the lack 
of functional locking within Windows/WSL.


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?

TortoiseSVN uses the Subversion libraries directly, it doesn't run the svn 
command line client. Obviously it should be possible to have some service 
running under WSL that TSVN can access to run the Subversion libraries 
within WSL, but I think that is a quite significant rewrite. I believe it 
would be better to continue to push Microsoft to implement proper locking 
with WSL2.

Kind regards,
Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tortoisesvn+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tortoisesvn/078065a6-df53-484a-a26b-199fcff7ef9an%40googlegroups.com.

Re: TortoiseSVN not working on folders of WSL2

[TortoiseSVN]

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

On Thu, Jan 26, 2023 at 10:34 AM Daniel Sahlberg via TortoiseSVN <
tortoisesvn@googlegroups.com> wrote:

> torsdag 26 januari 2023 kl. 08:48:27 UTC+1 skrev johan@gmail.com:
> Hi,
>
> We are having a problem with TortoiseSVN 1.14.5, Build 29465 - 64 Bit and
> earlier versions. When we want to clone, update or commit with a working
> copy that is placed under a WSL2 folder, TortoiseSVN does not work.
> The issue is already reported by others on WSL issue tracker:
> https://github.com/microsoft/WSL/issues/4689.
>
> I understand the issue is caused by SVN itself (actually the sqlLite
> database used internally) but I was wodnering if somebody has some
> workaround for this?
>
> Are more people suffering from this problem?
> We think  TortoiseSVN is great and we also believe WSL is great. It would
> be awesome to be able to combine those.
>
> I think you analysis is correct and I can't find any way to disable the
> SQLite locking.
>
> There is also a separate issue in the sqlitebrowser project:
> https://github.com/sqlitebrowser/sqlitebrowser/issues/2142
>
> Can you work around the issue by placing the working copy within Windows
> and accessing it through /mnt/driveletter/path from WSL?
>
> Please be aware that TortoiseSVN is using Windows-style line endings
> (CRLF) whereas most Unix tools (including Subversion under WSL)
> expect/require Unix-style line endings (plain LF). Subversion has support
> to translate source files on commit/update, see the svn:eol-style property.
> If this is used and Subversion encounter a file with unexpected line
> endings (for example if you use the svn command line client in WSL on a
> working copy created by TortoiseSVN) you will run into problems.
>
> Kind regards,
> Daniel
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "TortoiseSVN" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/tortoisesvn/nYyM9BEr1Xo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> tortoisesvn+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tortoisesvn/ae5c9792-1eeb-4fe1-aca5-15df76261043n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tortoisesvn+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tortoisesvn/CAN69bir-8g3wKC8%3DXCnBbDdiv%2BFDwHuM7SDm50X3oKBvcsHvFw%40mail.gmail.com.

Re: TortoiseSVN not working on folders of WSL2

[Daniel Sahlberg via TortoiseSVN]

torsdag 26 januari 2023 kl. 08:48:27 UTC+1 skrev johan@gmail.com:
Hi,

We are having a problem with TortoiseSVN 1.14.5, Build 29465 - 64 Bit and 
earlier versions. When we want to clone, update or commit with a working 
copy that is placed under a WSL2 folder, TortoiseSVN does not work.
The issue is already reported by others on WSL issue tracker: 
https://github.com/microsoft/WSL/issues/4689.

I understand the issue is caused by SVN itself (actually the sqlLite 
database used internally) but I was wodnering if somebody has some 
workaround for this?

Are more people suffering from this problem?
We think  TortoiseSVN is great and we also believe WSL is great. It would 
be awesome to be able to combine those.

I think you analysis is correct and I can't find any way to disable the 
SQLite locking.

There is also a separate issue in the sqlitebrowser project: 
https://github.com/sqlitebrowser/sqlitebrowser/issues/2142

Can you work around the issue by placing the working copy within Windows 
and accessing it through /mnt/driveletter/path from WSL?

Please be aware that TortoiseSVN is using Windows-style line endings (CRLF) 
whereas most Unix tools (including Subversion under WSL) expect/require 
Unix-style line endings (plain LF). Subversion has support to translate 
source files on commit/update, see the svn:eol-style property. If this is 
used and Subversion encounter a file with unexpected line endings (for 
example if you use the svn command line client in WSL on a working copy 
created by TortoiseSVN) you will run into problems.

Kind regards,
Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tortoisesvn+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tortoisesvn/ae5c9792-1eeb-4fe1-aca5-15df76261043n%40googlegroups.com.