Re: Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Joerg Wunsch
As Daniel Shahaf wrote: > Joerg Wunsch wrote on Thu, 23 Jan 2020 22:18 +0100: > > Would having at least an option to "svn co" that does just not > > traverse upwards (for those who know what they are doing) be a > > compromise? > > In general, we don't like adding options, [...] Understood. >

Re: Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Paul Hammant
Works for me (svn, version 1.13.0 (r1867053) on Mac) $ svn co https://svn.freebsd.org/base/head/usr.bin/passwd freebsdTest AfreebsdTest/Makefile AfreebsdTest/passwd.c AfreebsdTest/Makefile.depend AfreebsdTest/passwd.1 Checked out revision 357040.

Re: Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Joerg Wunsch
As Paul Hammant wrote: > Works for me (svn, version 1.13.0 (r1867053) on Mac) > > $ svn co https://svn.freebsd.org/base/head/usr.bin/passwd freebsdTest > AfreebsdTest/Makefile > AfreebsdTest/passwd.c > AfreebsdTest/Makefile.depend > AfreebsdTest/passwd.1 > Checked out

Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Joerg Wunsch
I'm trying to checkout part of the official FreeBSD SVN repository on a FreeBSD machine where my $HOME is automounted (through FreeBSD's automounter). This always fails: joerg@daemon ~% svn co https://svn.freebsd.org/base/head/usr.bin/passwd svn: E05: Can't check path '/home/.svn/wc.db':

Re: Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Vincent Lefevre
On 2020-01-23 12:44:02 +0100, Joerg Wunsch wrote: > If the automounter already yields ENOENT for the ../.svn directory > probe, everything is not going to be a problem. I think the point here > is the automounter (eventually, after "thinking" about it for about 1 > s) offers a successful stat()

Re: Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Daniel Shahaf
Joerg Wunsch wrote on Thu, 23 Jan 2020 21:16 +0100: > As Daniel Shahaf wrote: > > However, on FreeBSD a plain «stat /nonexistent/foo/bar» > > returns ENOENT, not ENOTDIR… > > The semantics of that automounter are, indeed, a bit strange. I would > have expected an ENOENT for ../.svn (the NFS

Re: Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Joerg Wunsch
As Daniel Shahaf wrote: > Well, I don't know whether those semantics are configurable, but you > might be able to duct tape around them by creating /home/.svn as a local > directory: Hmm. Looks strange. ;-) > > But that's another point. I was more suprised about "svn checkout" > > traversing

Re: Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Daniel Shahaf
Joerg Wunsch wrote on Thu, 23 Jan 2020 12:44 +0100: > My entire point is: when getting any error for ..*/.svn/wc.db, just > stop traversing there, and proceed with the checkout (in its own > new directory). This change is not likely to be accepted. As your ktrace shows, Subversion does a

Re: Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Daniel Shahaf
Vincent Lefevre wrote on Thu, 23 Jan 2020 15:50 +0100: > On 2020-01-23 12:44:02 +0100, Joerg Wunsch wrote: > > If the automounter already yields ENOENT for the ../.svn directory > > probe, everything is not going to be a problem. I think the point here > > is the automounter (eventually, after

Re: Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Joerg Wunsch
As Daniel Shahaf wrote: > However, there might be other things we could do. First, it is possible > to create nested checkouts in general, so perhaps the "Are we already > inside a working copy?" check is superfluous. That is, perhaps «svn co > $URL $dir» shouldn't check $dir's ancestors for

Re: Subversion fails to checkout new working set when $HOME is automounted

2020-01-23 Thread Daniel Shahaf
Joerg Wunsch wrote on Thu, 23 Jan 2020 22:18 +0100: > Would having at least an option to "svn co" that does just not > traverse upwards (for those who know what they are doing) be a > compromise? In general, we don't like adding options, because every option added is another variable to account