As Daniel Shahaf wrote: > 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:
Hmm. Looks strange. ;-) > > 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: There are arguments for that, I see. 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? 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=/. *) Sure, for "modern" root accounts, this would limit all SVN searches to /root. However, it can be argued that root always needs to know what she is doing so the entire traversal is not necessary for root. :) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)
