Den sön 13 nov. 2022 06:10Nathan Hartman <hartman.nat...@gmail.com> skrev:
> On Fri, Nov 11, 2022 at 3:58 PM Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > >> Daniel Shahaf wrote on Mon, Oct 31, 2022 at 10:02:14 +0000: >> > Vincent Lefevre wrote on Mon, 24 Oct 2022 13:57 +00:00: >> > > "svn" goes up in the directory hierarchy to look for a .svn directory. >> > > The issue is that it doesn't stop at filesystem and/or owner change. >> > >> > Why should the upwards scan stop at mount points? Because accessing >> > /home/.svn on a random machine in your lab hangs? That's insufficient >> > justification. > > > > FWIW git stops scanning upwards at a filesystem boundary by default; IIRC > some command line switch overrides that. I don't have example output handy > (writing this on my phone). > > > Because if the .svn directory were on a different mount point, >> a subsequent «svn update» might attempt to atomically rename(2) something >> from .svn/ into the ACTUAL tree, and fail because they're not on the >> same device? >> >> Example: If /h/home is a mountpoint and jrandom does 'svn up' in >> /h/home/jrandom, then even if /h/.svn exists, atomic renames from >> /h/.svn/tmp/foo to /h/home/jrandom/path/to/wc/bar wouldn't be possible. >> Is this a good reason not to look for /h/.svn or /.svn at all (i.e., to >> recurse upwards no further than to /h/home/.svn)? >> > I tried to do it but failed, as Danielsh suspected above: [[[ Updating '.': svn: E155009: Failed to run the WC DB work queue associated with '/home/dsg/multimntpntwc/foo/file.txt', work item 5 (file-install foo/file.txt 1 0 1 1) svn: E000018: Can't move '/home/dsg/multimntpntwc/.svn/tmp/svn-p5XxYe' to '/home/dsg/multimntpntwc/foo/file.txt': Invalid cross-device link ]]] In my example, I created multimntpntwc/foo and checked out a filesystem on foo. Then I tried to checkout on to the non-empty directory. On Windows, with foo being a directory junction pointing to a directory on another disk, it fails with a similar error message: "Unable to move the file to another disk drive" <my translation from Swedish>. How could a working copy end up spanning filesystems? I can think of two > ways: (1) a checkout into a non-empty directory, in which some subdirectory > is a mountpoint; if that subdirectory shares the same path as a versioned > subdirectory, the former will occlude the latter. Or (2) a user checks out > a working copy and then mounts a filesystem onto one of the subdirectories. > > Is there a reasonable use case for doing either of the above? > Define reasonable. If the wc is too large to fit on one device, you could mount a separate device within the WC tree. As far as I understand (1) it doesn't work right now and (2) you would need to jump through hoops to create such structure. Therefor I'm not sure it makes sense to support such use case. If we make changes similar to git's behaviour, we need to make sure the code also works on Windows, detecting directory junctions and symbolic links. Kind regards, /Daniel
