OK,
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:-)
gat
Karl Fogel wrote:
>"I think we're operating at the wrong level of generality here."
>
>Sorry. Jon Trowbridge once offered that as the unanswerable sentence
>you can say at any point, in any conversation. I've always wanted to
>try it out :-).
>
>-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
Received on Tue Nov 12 23:40:07 2002