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
Received on 2020-01-23 21:58:29 CET