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
