Invalid cross-link error when have a mounted subdirectory

[Jon Daley via users]

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

But, today, I installed a new server, and whenever I use subversion inside
my home directory, I get:

/home/mail#svn copy svn+ssh://svn@ASDASDASD .
svn: E155009: Failed to run the WC DB work queue associated with '/home/mail', work item 3470 (file-install home/mail/.no-spam-check 1 0 1 1)
svn: E000018: Can't move '/.svn/tmp/svn-U1XHuf' to '/home/mail/.no-spam-check': Invalid cross-device link

Is there a way to make subversion not assume its tmp directory is on the
same disk as the working directory?

[Nico Kadel-Garcia]

On Sun, Aug 7, 2022 at 8:40 AM Jon Daley via users
<us...@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?

Climbing up the directory tree past mountpoints is... well, it's a bit
dangerous.

[Nathan Hartman]

On Sun, Aug 7, 2022 at 12:13 PM Nico Kadel-Garcia <nka...@gmail.com> wrote:

On Sun, Aug 7, 2022 at 8:40 AM Jon Daley via users
<us...@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?

Also important: Which was the old version that worked as expected?

Do you have both versions available and can you run "svn version --verbose" and share the output?

Knowing both versions makes it possible to bisect (provided the issue can be reproduced).

Bisecting is probably the first avenue I would explore in any given "it used to work but now it's broken" situation.

Cheers,

Nathan 

[Jon Daley via users]

On Sun, 7 Aug 2022, Nico Kadel-Garcia wrote:
> On Sun, Aug 7, 2022 at 8:40 AM Jon Daley via users
> <us...@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. /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 also realized after my first posting that I can probably
checkout /home separately from the / repo, which will fix the problem, I
think. 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.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766285

https://lists.apache.org/thread/8qggy35hbft1q88jjqnyjlkb49pvr0zr


--
Jon Daley
https://jon.limedaley.com
~~
Just because something is tradition doesn't make it right.
-- Anthony D'Angelo

[Daniel Shahaf]

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
> > <us...@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
>
>

[Jon Daley via users]

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.