Hello,
McKenna, Simon (RGH) wrote on 21/04/2005 6:37:
>I've got a similar system working (outside of perl/python-land)
>which is doing much the same thing and have been pondering a
>few issues:
>
>- Is it better to have hook:commit-email per file or per directory?
> I prefer the 'bugtraq' approach and look on the directory of each
> file committed using 'svnlook dirs-changed' for the revision.
>
>
Would this make a lot of difference? I would like to receive updates for
"parent/subparent/file" by only setting the property on "parent". As I
understand dirs-changed, it will report "parent/subparent", so I still
have to walk this reported path upwards to check for properties.
Nevertheless, maybe svn properties would benefit from recursive
properties. This could also ease the setting of e.g. svn:keywords or
svn:eol-style for all files of an existing project at once, or for all
new files of a project automatically.
>- Should there option for hook:propchange-email property? so that
> property changes on a file or directory can be handled independently,
> but in much the same way, except using the post-propchange hook.
>
>
I think this would definitely be possible. Note that the commit-email.pl
script already reports property changes.
>- Do you handle multiple email addresses per property?
> (eg. my approach accepts comma and line delimited addresses)
>
>
Yes, similar to other svn properties, it's a multi-line property, one
email address per line.
>- Is it sane to extend concept further to govern repository access?
> (eg. for those who using ra_svn/svnserve and need fine-grained control)
>[...] 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 :)
>
>
This might be a good idea since it can make the style of configuring
authorization less arbitrary than it looks now (through
AuthzSVNAccessFile). It would also be an appropriate to configure
authorization for multiple repository access methods (svnserve, httpd)
in one central place. A downside is that it looks unnatural to have
these configuration properties versioned. E.g. in the case of read
access control, since configuration properties are different on old
revisions, 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?
Regards,
Bruno
--
Bruno De Fraine
Vrije Universiteit Brussel
Faculty of Applied Sciences, INFO - SSEL
Room 4K209, Pleinlaan 2, B-1050 Brussels
tel: +32 (0)2 629 29 75
fax: +32 (0)2 629 28 70
e-mail: Bruno.De.Fraine@vub.ac.be
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 21 11:07:17 2005