You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2001/08/10 00:34:48 UTC
Re: CVS update: ADDED: subversion/include svn_config.h
On Thu, Aug 09, 2001 at 11:42:16PM -0000, brane@tigris.org wrote:
>...
> - Option values may be expanded within a value by enclosing the
> option name in parentheses, preceded by a percent sign:
>
> %(name)
>
> The expansion is performed recursively and on demand, during
> svn_option_get. The name is first searched for in the same section,
> then in the special [DEFAULTS] section. If the name is not found,
> the whole %(name) placeholder is left unchanged.
>
> Any modifications to the configuration data invalidate all
> previously expanded values, so that the next svn_option_get
> will take the modifications into account.
>...
Is this feature truly needed? I've never seen/used it in all the time that
I've used ConfigParser (which was even before it was part of the Python
distro...).
It is a rather complex feature, and I would think for marginal benefit. I'd
recommend dropping it unless we have a firm requirement for it. Any
examples?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVS update: ADDED: subversion/include svn_config.h
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>On Thu, Aug 09, 2001 at 11:42:16PM -0000, brane@tigris.org wrote:
>
>>...
>> - Option values may be expanded within a value by enclosing the
>> option name in parentheses, preceded by a percent sign:
>>
>> %(name)
>>
>> The expansion is performed recursively and on demand, during
>> svn_option_get. The name is first searched for in the same section,
>> then in the special [DEFAULTS] section. If the name is not found,
>> the whole %(name) placeholder is left unchanged.
>>
>> Any modifications to the configuration data invalidate all
>> previously expanded values, so that the next svn_option_get
>> will take the modifications into account.
>>...
>>
>
>Is this feature truly needed? I've never seen/used it in all the time that
>I've used ConfigParser (which was even before it was part of the Python
>distro...).
>
I found this feature immensely useful for programs that look for
components places relative to the installation directory. Many Unix
packages today expect to be installed in a specific directory (/opt/foo,
/usr/local, ...), and can't be relocated. That's often a pain. (Yes,
--rpath is evil.)
>It is a rather complex feature, and I would think for marginal benefit. I'd
>recommend dropping it unless we have a firm requirement for it. Any
>examples?
>
Well, let's take the problem that popped up recently -- finding the RA
libraries. With variable expansion, you could set up your /etc/svn.conf
like this:
[DEFAULTS]
# Installation prefix, set up by "make install" or other scrip
prefix: /opt/subversion
# File name extension of shared libraries, guessed by configure
# (this one is for HP-UX)
.so: .sl
# Paths to installed Repository Access libraries
[ra_libs]
ra_local: %(prefix)/lib/libsvn_ra_local%(.so)
ra_dav: %(prefix)/lib/libsvn_ra_dav%(.so)
# Paths to uninstalled RA libraries, for testing
[ra_libs.test]
ra_local: %(exepath)/../../libsvn_ra_local/.libs/libsvn_ra_local%(.so)
ra_dav: %(exepath)/../../libsvn_ra_dav/.libs/libsvn_ra_dav%(so)
Then, in svn, you set up the variables:
/* Absolute path to svn */
svn_config_set (cfg, "DEFAULTS", "exepath", dirname(fullpath(argv[0])));
and have the RA loader look at [ra_libs.test] or [ra_libs] to find the
correct paths.
Granted, this may not seem very useful for svn right now, but I think it
will become so, e.g., once we support client-side hooks. I'm also sort
of hoping that /all/ SVN clients will use the same configuration files,
as far as humanly possible.
Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVS update: ADDED: subversion/include svn_config.h
Posted by Bruce Atherton <br...@flair.law.ubc.ca>.
At 05:34 PM 8/9/01 -0700, Greg Stein wrote:
>On Thu, Aug 09, 2001 at 11:42:16PM -0000, brane@tigris.org wrote:
> >...
> > - Option values may be expanded within a value by enclosing the
> > option name in parentheses, preceded by a percent sign:
> >
> > %(name)
> >
>
>Is this feature truly needed? I've never seen/used it in all the time that
>I've used ConfigParser (which was even before it was part of the Python
>distro...).
I use a similar concept all the time. Consider release management. You may
have an integration machine, a QA machine, and a Production machine. If you
have a configuration file set up like so -
# Generic configuration - urls used by our project
hostname=integration.domain.org
port=80
basepath=/myproduct
url-login=http://%(hostname):%(port)/%(basepath)/login
url-logout=http://%(hostname):%(port)/%(basepath)/logout
url-function-1=http://%(hostname):%(port)/%(basepath)/whatever
.
.
url-function-9999=http://%(hostname):%(port)/%(basepath)/lastfunction
Then you can have a very simple configuration file for QA -
# QA Configuration
hostname=qa.domain.org
You could also test your system with Apache 2.0 by running it on another
port and writing a one line (plus comment) configuration file -
# Apache 2 test
port=8080
Sandboxes can be dealt with similarly, with each user defining their own
port or basepath or hostname, depending on how things are set up. This
saves you from trying to keep all of the URLs in sync in separate
configuration files for each environment. Your program always loads the
generic configuration file, and then allows overrides on particular pieces
of each entry with a second configuration file.
Does any of this apply to Subversion and it's configuration file? I'm not
certain but I suspect so. Release management will be a layer that is
commonly placed over Subversion, right? You may want to special case stuff
that occurs on particular branches, for example. I'd like to see that
feature kept.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org