[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: Joerg Wunsch <j_at_uriah.heep.sax.de>
Date: Thu, 23 Jan 2020 21:16:03 +0100

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

For everything else except "checkout", I completely agree that
traversing upwards needs to be done.

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

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.

-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
Received on 2020-01-23 21:16:09 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.