Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for 
change notification.

The "InRepoAuthz" page has been changed by BenReser:
http://wiki.apache.org/subversion/InRepoAuthz?action=diff&rev1=4&rev2=5

Comment:
Make reasons for not using hook script clearer and fix a typo.

  
  It is desirable to store Authz files inside a Subversion Repository 
(potentially the same repository the file is written to protect).  By placing 
the file in Subversion you gain versioning and the audit trail that comes with 
it.  Additionally, it simplifies replication since your Authz file is no longer 
out of band.
  
- This can already be achieved by writing hook scripts that export the Authz 
file from Subversion on commit.  However, it may be undesirable to use a hook 
script in cases where Authz is being managed by a 3rd party GUI and requiring a 
hook script in every installation would potentially conflict with other hook 
scripts.
+ This can already be achieved by writing hook scripts that export the Authz 
file from Subversion on commit.  However, it is more difficult to install a 
hook script setup than it is to simply set a configuration parameter.  The hook 
script solution is also very difficult to validate proper installation.
  
  === Behavioral Specification ===
  
@@ -26, +26 @@

  
  === SVNParentPath Operation ===
  
- mod_auth_svn uses two different configuration options with different roots.  
AuthzSVNAccessFile which is relative to the ServerRoot and 
AuthzSVNReposRelativeAccessFile which is relative to the conf directory of the 
repos being accessed, in order to allow different Authz files for different 
repos with SVNParentPath.
+ mod_authz_svn uses two different configuration options with different roots.  
AuthzSVNAccessFile which is relative to the ServerRoot and 
AuthzSVNReposRelativeAccessFile which is relative to the conf directory of the 
repos being accessed, in order to allow different Authz files for different 
repos with SVNParentPath.
  
  Both of these commands should take the two new formats.  Neither of the two 
new formats (`file://` or `^/`) care about the root for relative file paths.  
There is a small amount of extra overhead for AuthzSVNReposRelativeAccessFile 
in finding the conf dir of the repo, but we can shortcut it when we see 
`file://` or `^/` values.
  

Reply via email to