Jon Daley via users wrote on Mon, Aug 08, 2022 at 05:12:37 -0400: > On Sun, 7 Aug 2022, Nico Kadel-Garcia wrote: > > On Sun, Aug 7, 2022 at 8:40 AM Jon Daley via users > > <users@subversion.apache.org> wrote: > > > > > > I'm not sure what version this change happened in, but I used to be able > > > to have my /home directory mounted and use subversion commands in my home > > > directory, even though the .svn directory exists at /.svn > > > > Which version are you using, and on which operating system? > Debian Bullseye 11.4. Subversion version 1.14.1 (r1886195). I had > assumed > this would be a known issue on a new version, so I hadn't looked into it > further, but I have another system with the exact same version, but it > works, so it must be a different of the repo or something? /.svn/format is > 12 for both.
The term is "working copy". The format number is given by `sqlite3 .svn/wc.db 'pragma user_version;'`. > /etc/subversion/config and ~/.subversion/config are all empty. > > > Climbing up the directory tree past mountpoints is... well, it's a bit > > dangerous. > I understand, and I saw some people using removable drives, which sounds > dangerous to me. I don't see any issues with permanently mounted drives; I > understand there is probably a performance increase by doing some sort of > rename or hard-link or something that only works on one filesystem, but it'd > be nice to either detect that it is across filesystems (which would reduce > the performance increase) or have a config setting that puts it in slow > mode. I suspect it's done this way not for performance reasons but in order to take advantage of rename(2)'s atomicity guarantees. E.g., that's why an 'update' that's SIGKILLed partway, and leaves some items with 'L' in `svn status`, won't leave unversioned files or half-written versioned files behind. > I also realized after my first posting that I can probably checkout > /home > separately from the / repo, which will fix the problem, I think. +1 > I just noticed that I reported this same bug years ago, and it was > "resolved" by fixing the documentation, so I guess that is the end. > It is interesting that it works on some systems. > Presumably rename(2) doesn't return an error on those systems. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766285 > > https://lists.apache.org/thread/8qggy35hbft1q88jjqnyjlkb49pvr0zr > >
