"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
Received on Tue Nov 12 23:33:29 2002