[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Commit-emails + access control using SVN properties (was: Configu ring commit e-mails ...)

From: McKenna, Simon (RGH) <Simon.McKenna_at_rgh.sa.gov.au>
Date: 2005-04-22 09:47:35 CEST

Hello again Bruno!

-> Would this make a lot of difference? I would like to receive
-> updates for "parent/subparent/file" by only setting the property
-> on "parent".

Cool, we're on the same wavelength.

After reading Nathan's PHP commit-email script (thanks for sharing!)
and seeing the way he was sending out emails, another thought
popped up on the bike-ride home from work...instead of just having
the email address(es) defined in the hook:commit-email property,
you could cater for additional information by (optionally) using
a key=value pair for each address, with the value being a comma
separated subset of svnlook subcommands. The default would still
be a diff if no = was found, but something like:

autobot1@example.com
autobot2@example.com=author,log,diff
autobot3@example.com=author,date,changed,log

Then just concatenate each svnlook result into the email.

Should be useful as some folks aren't always interested in what
has changed, rather who or why or when or where it was changed,
and they could also choose how the order is displayed...all nicely
controlled and versioned from within the repository.

-> >- Is it sane to extend concept further to govern repository access?
[...]
-> >The general idea being we create an extensible yet enforceable
-> >system to control who can do what from within svn properties and
-> >visible to anyone allowed to browse the repository, without having
-> >to annoy the repo administrator when changes are needed :)

[...]

-> ...would a user have different rights on an old
-> revision of a path than on a new one, or would you always
-> apply the configuration of the HEAD?

Always using HEAD would probably be the cleanest way.
This is same approach 'bugtraq' adopts when looking for it's
properties, and it is how I'm reading the hook:commit-email
property. Seems to work pretty well.

Are there any plans for a pre-checkout hook in Subversion?

Couldn't find anything in the issue tracker or anything recent
in google, and it would be good to have, as this should enable
complete access control through SVN properties.

I'll have a bash at implementing the spec below on my own
project (subnant), and will see how well it works.

If anyone has already tried this approach, or can see any
pitfalls, constructive feedback would be appreciated!

Here's a first draft of the spec:

---------------------------------------------------------
Using Subversion properties for repository access control

Using Subversion repository properties in conjunction with Subversion
server pre-processing hooks, we can provide a granular, visible and
versioned mechanism for access control independent of the repository
access method.

Two properties are required to enable this, these properties can exist
on individual files or directories, or on the parent directories of
files or directories you wish to control.

hook:propchange-access
----------------------
This property contains a line delimited list of properties and a comma
separated list of users who are allowed to modify each property.

To enable access control this property needs to set 2 property values,
the first controls who is allowed to modify the hook:propchange-access
property, the second controls who is allowed to modify the
hook:commit-access property.

e.g. To give user "admin" rights to control who is allowed to modify
the hook:propchange-access property, and users "admin" and "user"
rights to modify the hook:commit-access property for the repository,
the hook:propchange-access property is set to the following values
on the repository root:

hook:propchange-access=admin
hook:commit-access=admin,user

hook:commit-access
------------------
This property contains a line or comma delimited list of users who are
allowed to commit the file or directory attached to the property.
In the case of a directory, it also determines which users are allowed
to commit on any of its sub-directories.

These properties are used with an appropriate hook script to determine
if the modification should be permitted.

pre-revprop-change
------------------
This hook script checks to see if there are any hook:propchange-access
properties, and if found verifies that the user making the change is
permitted to do so.

pre-commit
----------
This hook script checks to see if there are any hook:commit-access
properties, and if found verifies that the user committing the change
is permitted to do so. This hook script enables repository,
directory or file access control per user.

start-commit
------------
This hook script checks to see if there are any hook:commit-access
properties on the repository root, and if found, verifies that the
user committing the change is permitted to do so. This hook script
enables repository access control per user.

Note:
- All hook scripts should search HEAD for appropriate property.
- All hook scripts should search up the directory tree back to the
repository root, searching each parent directory for a match on the
appropriate property.
----------------------------------------------------------

If a pre-checkout hook is added to Subversion in the future, we
can add another property - hook:checkout-access, define a standard
user for anonymous access, and the rest should be the same.

Thoughts?

peace
si

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 22 09:48:12 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.