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 server in question does > not provide the respective directory). I'm not sure whether this would > be difficult to fix or not.
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: . % r=`mktemp -d` % wc=`mktemp -d` % svnadmin create $r % svn co --depth=empty file://$r $wc % mkdir /home/.svn % mount … /home/.svn # bypass the automounter for .svn/ % mv $wc/.svn/* /home/.svn/* % rm -rf $d $wc This fakes a valid working copy. > But that's another point. I was more suprised about "svn checkout" > traversing upwards at all, as I think this violates the principle of > least astonishment. For context, one of the reason it does this is to make the following error possible: % svn info --show-item=url https://svn.apache.org/repos/asf/subversion/trunk % svn ls | grep notes notes/ % rm -rf notes % mkdir notes % cd notes % svn co -q https://svn.freebsd.org/base/head/usr.bin/passwd ./ ./subversion/svn/checkout-cmd.c:175, ./subversion/libsvn_client/checkout.c:228, ./subversion/libsvn_client/checkout.c:173: (apr_err=SVN_ERR_WC_OBSTRUCTED_UPDATE) svn: E155000: '/home/daniel/src/svn/t1/notes' is already a working copy for a different URL zsh: exit 1 % The error is saying that the checkout would cause the notes/ subdirectory of the parent working copy to be obstructed (status '~'). We could make the failure mode less fatal in some cases: for example, when the parent working copy's .svn directory is inaccessible, we could issue a warning and continue. I'm not sure whether there are other reasons for the upwards scan. > > 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 .svn/ subdirectories. > > (Checking $dir/.svn is probably fine.) > > I'd vote for that. > > FWIW, this is also in a line what e.g. git does: if I'm inside a git > cloned repository / working copy, and perform another "git clone", I > get a new copy inside the already existing one. To be clear, Subversion behaves this way too. Cheers, Daniel