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
Received on Sat Oct 21 14:36:35 2006