On 16.05.2015 20:34, Ivan Zhakov wrote: > On 15 May 2015 at 07:04, Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> wrote: >> Thank you to everyone who answered! From what I gathered >> so far is this: >> >> to (1) Requirering recursive or non-recursive write on a copy target >> should not make a difference to a typical authz setup with the >> current /trunk code. However, the provided paths *is* a change >> that should not be committed to /trunk as is. >> >> Reducing the required access rights to just non-recursive write >> to a copy target makes sense. So, 3rd party distributions may >> use the patch (e.g. to solve issues with wildcard use cases) >> if they are able to communicate the change in behavior to their >> users. Their risk is that new SVN releases will address this >> problem differently. >> >> to (2) Requirering write access to the target *and* its parent, i.e. >> today's behavior, should be kept for the time being. No compelling >> argument can be given at this time that makes checking only the >> parent the clearly better option >> >> to (3) Delete (hence, move) should continue to require recursive >> write access to the (source) path. Otherwise, we would change >> the intended behavior of existing setups. >> >> Further feedback: >> >> * Ideally, we would traverse the actuall sub-tree and check against >> the authz rules instead of using the authz recursion approximation. >> >> * mod_dav might perform that recursion by default. From talking >> to Ben, it seems though that is probably not the case. >> >> Idea how to solve the issue in SVN proper: >> >> * Introduce c(reate) and d(elete) access rights. The data structures >> on the authzperf branch have plenty of unused bit flags left. >> > FWIW: Note that tag creation usually consist copy + modify some files > in commit. Like svn_version.h in our case [1]. I mean that granting > 'create' access to tags folder wouldn't be enough to allow tags > creation, but prevent commits to them.
Sure. But that's a case of adapting the workflow to the tool; we take advantage of the fact that Subversion doesn't have real tags. If it did, our workflow would probably have been different, too. In most CM workflows I've ever seen, a tag is assumed to be a read-only snapshot since its creation. FWIW, even with the required authz support in place, we still wouldn't have real tags, just as we don't have real branches; there's more to the semantics of these concepts than just access patterns. -- Brane
