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,
Agreed.
> but dragging the concept of a $HOME directory into subversion is
> certainly going too far.
Agreed.
> 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?
Cheers,
Daniel
Received on 2020-01-24 01:33:06 CET