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)? > 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? Thanks Nathan
