> On Wed, Dec 15, 2010 at 8:50 AM, Andy Levy <andy.levy_at_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 <nkadel_at_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
qazwart_at_gmail.com
Received on 2010-12-17 16:34:31 CET