Hi, In a thread started by Vincent Lefevre in October [1] there was a discussion about the way Subversion is looking for the working copy root by walking the path towards the root directory.
In the original thread, there was an argument about security implications if a malicious user create an SVN working copy (ie, the .svn directory and its contents) above the current working directory (the example given was /home/.svn and a user running an svn command in their home directory). The security implications have been discussed on security@ and there is consensus that the scenario is plausible, however if someone has this level of access, more malicious things can probably be achieved without going through an SVN working copy. There are also legitimate use cases where two users share a single WC and the svn client is unable to discriminate between these. However having a working copy span multiple file systems currently fails. As analysed by Danielsh in [2]: "atomic renames from [xxx] to [yyy] wouldn't be possible [when xxx and yyy are on different filesystems]", this was also verifyed by me in [3]: [[[ Updating '.': svn: E155009: Failed to run the WC DB work queue associated with '/home/dsg/multimntpntwc/foo/file.txt', work item 5 (file-install foo/file.txt 1 0 1 1) svn: E000018: Can't move '/home/dsg/multimntpntwc/.svn/tmp/svn-p5XxYe' to '/home/dsg/multimntpntwc/foo/file.txt': Invalid cross-device link ]]] It fails similarly on Windows with "junctions" (basically directory mount points). Nathan Hartmann [4] noted that git by default does not operate on repositories spanning multiple filesystems, but with a command line option to allow it. As such WCs currently don't work, I suggest that we change svn's behaviour to the same as git's default. If we decide on duplicating git's behaviour with a command line option, we must also make such working copies functional and this must be tested properly in the test suite. I'm not sure if it is worth this effort. Kind regards, Daniel Sahlberg [1] https://lists.apache.org/thread/1m0yhsgj6vnb15h23p9h689qp597fhgm [2] https://lists.apache.org/thread/672yotxjbynpln21nk5fsvx50vo62778 [3] https://lists.apache.org/thread/bbyvx5qo6xwpkzc5vovyf9l09bwt6kht [4] https://lists.apache.org/thread/zqzr241yd72c32ztg82m6qppo0v1c23g
