"Glenn A. Thompson" <gthompson@cdr.net> writes:
> I'll bite. What do you mean? Are you saying I'm on crack. I'm big
> boy I can handle being told that I'm on crack:-)
Heh :-). No, just that this seems to me like premature
generalization, and in any case we should make the decision based on
the code we currently have
Our hook system works fine as it is, except for the [eminently
solveable] bug that the hooks don't get invoked under Windows, due to
extension lossage. Fixing that bug doesn't require adding yet another
configuration system, and since such a system wasn't on the radar
before, I question whether it should suddenly be on the radar now.
-K
> >"Glenn A. Thompson" <gthompson@cdr.net> writes:
> >
> >>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
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> >For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
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:53:06 2002