Hi, > -----Original Message----- > From: Cooke, Mark [mailto:mark.co...@siemens.com] > Sent: Friday, March 25, 2011 12:38 PM > To: Jans Ullrich; subversion-20...@ryandesign.com > Cc: users@subversion.apache.org > Subject: RE: Unexpected behaviour with SVNPath/SVNParentPath mixture > > > The question is, why not? According to the Apache docs, it > > should work, so it looks like a problem in subversion. Can > > this be considered a bug? Should I file an issue? > > ...because when you use the SVNParentPath directive, apache has no > further involvement in any "child" paths, all paths that start with the > parent root are passed to the DAV handler... You can get round this by > specifiying separate handlers for the separate paths using multiple > SVNPath blocks but again, anything below those paths is handled by DAV > and not apache. > > This is different from nesting access restrictions to artifacts that are > all handled by apache (i.e. uri <Location>s or local <Directory>s so > those docs you mention do not apply in this scenario.
Thanks for the explanation. I think I get it now, just the effect with the path component suddenly doubling still puzzles me a bit. I still suspect a bug or misfeature there, since I'd have thought it should either work not at all or work as expected. But since it looks like we have a workaround, I guess I can live with that. > > We'd like to provide our users with the ability to create > > repositories themselves, then possibly promote select > > repositories to a different permission set. Restricting > > ourselves to only using SVNPath would be inconvenient... ;-) > > You could consider using one (set of) parent path(s) for restricted > repos and another (set) for less restricted ones? I'll have to check that, but I suspect it will be hard because a lot of our build architecture is already using these paths. The modified permissions are the new part. But I think the idea is good, maybe we can have a completely different location for the SVNPath configs (like /svn/parentpathtest_ext/...) then we should have no conflict, should we? Thanks for the idea and the explanation above! Cheers, Ulli ---------------------------------------------------------------- Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
