[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: Fri, 24 Jan 2020 00:32:56 +0000

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 for in future maintenance, testing, user
support, etc.. I'd rather figure out a new, different behaviour that
we can roll out for everyone.

> That way, using the default behaviour:
> > ./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
> This would still trigger that error, but one could override it for
> situations where traversing beyond the current directory is just not
> wanted - for whatever reason. For mortal users, traversing into the
> OS domain beyond $HOME is usually not useful anyway,


> but dragging the concept of a $HOME directory into subversion is
> certainly going too far.


> Of course, if considering $HOME as a search boundary sounds really
> more reasonable, that entire directory traversal might be made more
> flexible. Suppose adding an option --topmost-search-directory, it
> could then default to $HOME. *) One could then completely avoid the
> traversal by using --topmost-search-directory=., or alternatively,
> allow for traversing the entire hierarchy with
> --topmost-search-directory=/.

Could we look for a solution that doesn't involve explicit user input?
For example, given «svn co $URL $dir», we could search only in
ancestors that are writable by the current user (in the sense of
access(W_OK)). That would generally cause the $HOME behaviour Jörg
proposed, but without special-casing $HOME.

As a separate question, I think the fatal error behaviour is
questionable. A user has any number of ways to obstruct their own
files, so why should «svn checkout» be the exception that goes out of
its way to prevent that outcome? Would it be reasonable to downgrade
the error to a warning?


Received on 2020-01-24 01:33:06 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.