> On Wed, Dec 15, 2010 at 8:50 AM, Andy Levy <andy.l...@gmail.com> wrote: > > If you just need to set the whole directory read-only unilaterally, > you don't need a pre-commit hook; just use the built-in path-based > authorization.
On Thu, Dec 16, 2010 at 12:57 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote: > Well, no, you don't *need* to do it that way. But each access method > has its own access control, whether svn or svn+ssh, file based, or > http/https. Rather than exerting cleverness, simply disabling all > writes in a clean and easily restored fashion, and one that is more > certain to be replicated by an svnadmin hotcopy, seems quite > reasonable. There are advantages to path based authorization and using a pre-commit hook. One advantage with path-based authorization is that you can create read (or more importantly "non-read" access). You can't do that with a hook. Path based authorization also uses fewer resources than a pre-commit hook. With path based authorization, the Subversion server can do the authorization as it does whatever processing it needs. With a pre-commit hook, the server has to run another program. Most pre-commit hooks run on an "O-squared" algorithm. Each file must be tested against each permission. If you are committing a few files, and you only have a few rules, the pre-commit hook is barely noticeable. But if you're committing thousands of files and checking them against thousands of arcane permissioning rules, your pre-commit hook execution time might start hitting the nuisance zone. However, a pre-commit hook has certain advantages. With a path based authorization and Apache, you have to bounce the server every time you change permissions. This can be difficult to do. Plus, changing the permissions might require approval of other individuals and departments since you're changing the Apache configuration. With a pre-commit hook, changing permissions is instantaneous and requires simply modifying the pre-commit hook configuration file. Something most Subversion admins can do on their own. Also a pre-commit hook puts the authorization in the Subversion repository directory where it gets backed up on a regular basis. If your Subversion server crashes and has to be rebuilt, you might not remember a highly detailed path-based authorization, but your pre-commit hook authorization list is safely backed up. Also, a pre-commit hook can do "add-only" authorization. This allows users to create a tag, but not modify the tag once it is created. A similar thing could be done with this "obsolete" directory: Technical leads can add branches and maybe projects into the "obsolete" directory, but no one can modify a file once it is there. My general rule of thumb is to setup gross permissions with the path based authorization -- especially those that depend upon no read access. For example, only people in the LDAP developer group can access our Subversion server, and only people in this department can modify their directory tree , but other developers will be able to read it. >From there, I use a pre-commit hook to fine tune it. For example, locking a branch or tag to prevent its modification. Or allowing only a few select users the ability to modify a release branch. This is mainly to prevent whoops scenarios. For example, a developer forgetting to "svn switch" from the branch to the trunk before they continue their development work. -- David Weintraub qazw...@gmail.com
