[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 23 Jan 2020 20:58:12 +0000

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

This is an archived mail posted to the Subversion Users mailing list.