Re: svn copy url1 url2 requires read access to repository root

Stefan Küng wrote:
> Hi,
>
> A user reported that TSVN would require read access to the repository
> root for an 'svn cp trunk tags/versionX'. I've checked and the copy
> fails if the user doesn't have read access to the repository root, even
> with full write access to both /trunk and /tags.
>
> The mail thread is here:
> http://groups.google.com/group/tortoisesvn-dev/browse_frm/thread/8e9d0c2154dc9e0a
>
>
> Since the same happens with svn 1.4.x (not just with the latest trunk
> build), I'm not sure if that's by design or not.

This from libsvn_client.copy.c:repos_to_repos_copy():

   /* We have to open our session to the longest path common to all
      SRC_URLS and DST_URLS in the repository so we can do existence
      checks on all paths, and so we can operate on all paths in the
      case of a move. */

Some of this is just the side-effect of using an editor drive to perform
these copies/moves, as an editor must be rooted at the longest common
directory of the things you wish to change. For moves, that means anchoring
at the directory common to all move sources and targets. For copies, it
means the directory common to just copy targets. I think for code
simplicity we use the former anchor-point calculation for both copies and
moves. The result is that copies can be anchored unnecessarily high in the
tree, and that we do some unnecessarily editor traversing (opening extra
directories till we get down to the one common to just the copy targets).

In some ways, this could be considered a bug, but the obvious fix doesn't
get us very far. In your use-case, anchoring lower in the tree for copies
would mean only needing read access on '/tags', but as soon as somebody
tries in one commit to do both 'cp /trunk /tags/1.1' and 'cp /trunk
/branches/branch', they're right back to needing read access to the root of
the repository. The *real* fix is either to make the authz checker smarter
(like, "don't fuss about someone doing an innocuous request on DIR if they
have read/write access to one of its descendents") or to get away from using
svn_delta_editor_t for this operation.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand