On Mon, 8 Aug 2022, Daniel Shahaf wrote:
Jon Daley via users wrote on Mon, Aug 08, 2022 at 05:12:37 -0400:
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;'`.
Yes, I did know that and wasn't precise - thanks. user_version is
31 for both.
/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.
Yes, probably true.
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.
Yeah, it must be, but given that the systems are so similar, I
wonder what the difference is. The one that is broken is an AWS
lightsail instance, and the other is my own physical RAID5 hardware, same
drive, but different partitions, so perhaps that is why it works.
I have gotten it to work this morning by doing a sparse checkout
up to the mount point and then setting the depth on the mount point to
infinity, and I've tested various operations trying to break it, and I
couldn't. I also tried svn:externals, but referring to the direct child
path, and subversion (rightly so) doesn't like that.
--
Jon Daley
https://jon.limedaley.com
~~
Use of excessive, unnecessary, commas, has always been,
one of my, pet peeves.
