1

Got a bit of an odd setup, perhaps.

I have put local checkouts of my SVN repository in Dropbox folders (Windows 11 machine).

So basically at any machine I work, I have the last edits whether they've been sent to SVN server or not. Plus, I can keep un-versioned documents and other non-code in the same directories, and they will be synced across machines, too.

It worked very well for me. Until I started to use Windows Subsystem for Linux 2 .

Nowadays, while I work on code from inside WSL OK, whenever I need to commit or update to/from SVN server, in about 70% of cases SVN will complain of Disk I/O error and occasionally corrupt its database. If you re-run commit, it might work. If you do svn cleanup and recommit, it might work or not.

This is usually resolved easily by doing the SVN commit/updates from Windows explorer side (I use TortoiseSVN), which work fine, and from which I can cleanup/repair database as well.

So it appears something to do with how WSL plays with things and how it or Dropbox deals with temporary files and file locking(? i presume).

Anyone else experienced something similar to this, with regard to Dropbox and/or WSL?

Any ideas or solutions appreciated.

4
  • What does your svn command look like?
    – harrymc
    Mar 17 at 12:21
  • 1
    This isn't surprising to me, but I haven't yet figured out exactly what the "flow" is that causes issues. See this Ask Ubuntu question that I think may be related. Mar 17 at 20:28
  • 1
    These "cloud storage filesystems" don't typically replicate everything on the local system, so there's often a delay while the file is copy from or to the cloud. I have a feeling this is causing issues with applications that aren't expecting that. To the Linux-side of things, it appears as a 9P mount shared from Windows (also a network filesystem), but then on the Windows-side there's a separate network interaction going on, and the two likely aren't synchronized. Just a theory at this point, or I'd write it up as an answer. Mar 17 at 20:28
  • @harrymc "svn update" or "svn commit -m '' "
    – Gnudiff
    Mar 18 at 14:47

1 Answer 1

0

The monster is dead

Looks like the well-known file locking problem of svn, but now it's gone. You can now safely use Dropbox and SVN together. I've been doing it since 2022 and there's no glitch in the matrix.

4
  • 1
    That doesn't address this question, which is using Dropbox in Windows through WSL. There is still a glitch glitch a glitch glitch in that particular (revision 7, perhaps) Matrix ;-) Apr 7 at 19:26
  • When was the last time WSL had this kind of problem? Does it still happen? I'm almost sure it's not there anymore.
    – dkellner
    Apr 8 at 9:47
  • 1
    As you can see from the date of the question, within the last 3 weeks. As I mentioned in the comments on the parent question, this is a common problem on WSL on many cloud-based filesystems, most likely due to the 9P locking behavior, not necessarily a problem in Dropbox itself. Apr 8 at 12:12
  • > I've been doing it since 2022 -- in fact. I've been using SVN Dropbox in wsl since wsl1 and the issue only have arisen in the past 3-5 months 🤷‍♂️ On both win 10 and win 11 boxes.
    – Gnudiff
    Apr 9 at 13:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.