Hey,
This brings up something I backed out the fs patch I'm working on.. My
solution was too specific to what I'm doing with my SQL stuff. Plus I
decided that it should be done in a separate patch.
I have locally changed the repos_create function and his fs counterpart
to take a svn_config_t reference.
I have a sql_config thing-a-ma-bob which eats svn_config_t's to provide
some convenience functions. The idea being that a single config file
would be provided to the svnadmin create which installs semi canned
"server configurations". Now where it really gets weird is that my
current wrapper class also provides a coalesce function which allows one
section to include another section. So the includee section would
become part of the the includer name space within the config. The idea
was to provide a check list config file to allow for custom server
behaviour to be installed without the access layers getting too
involved. If a config isn't passed, it works like it does now.
Anyhoo, the impl_pack stuff I started to implement requires yet more
config-like files. SOOOO, I want a config section for installing other
files into various sub directories. So I began to think the coalesce
stuff isn't required. If we simply had a a tidy way to install files
from a master config file I think it could be used by other FS modules
and maybe the repos layer and this would still give me the check-list
feel I was looking for.
In my case I need some of this information at create time so you can't
simply add the config files after fs creation. But if the repos layer
handled it, it could write the configs to disk in the create call prior
to calling the fs layer create function. My current plan is to get the
config information from the conf directory anyway for the
"open_fs/recover_fs/delete_fs" calls. The FS veneer layer was to make a
single svn_config_t structure available to FS implementations to use for
their own purposes. Right now, none of this is required. So I pulled
it to take a crack at something more general later.
So to address below: Would it be helpful to install hook config files
at create time in this manner?
gat
Branko Čibej wrote:
>Before I sign off for today, I'd like to share this in case I forget...
>
>Currently our repository hooks system is very Unixy, and in fact only
>works in Unix. That's because libsvn_repos tries to run specific files
>in the hooks/ directory, and on Windows, for example, those files don't
>have the right extension to be "executable".
>
>I'd like to change this: instead of looking for hard-coded file names, I
>propose the server should load a config file that defines the hook
>programs to run, e.g.:
>
>...repo/hooks/config:
> [global]
> pre_commit_hooks = access-check
> post_commit_hooks = commit-mail hot-backup
>
> [access-check]
> # the hook program
> hook_cmd = /usr/local/Python2.2/bin/python
>
> # number of args to hook program, without standard hook args
> hook_args = 2
>
> # args before the standard hook arguments
> hook_arg_1 = --verbose
> hook_arg_2 = access-check.py
>
> [commit-mail]
> # ...
>
>
>and so on, you get the idea.
>
>The hooks would be run in the order they're defined in the [glohal]
>section, and cwd of hook programs would always be the repo/hooks
>directory (or maybe that could be configurable, too). For backward
>compatibility, we'd still try to run the files that are used now, but I
>propose we deprecate that behaviour and remove it before Beta.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 12 23:05:39 2002