Melanie wrote:
And that brings us full circle to my proposal.
There is much sense in a set of files that are used as defaults, and
then overriding settings in specific configuration files.
+1 on that proposal.
DrS/dirk
--
dr dirk husemann virtual worlds research ibm
: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de] On Behalf Of Jeff Ames
Sent: Thursday, 5 March 2009 7:20 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Ini file(s) loading
Melanie wrote:
read [the config directory] first
.
- Original Message -
From: Dahlia Trimble
To: opensim-dev@lists.berlios.de
Sent: Tuesday, March 10, 2009 11:21 PM
Subject: Re: [Opensim-dev] Ini file(s) loading
Is there any reason why we wouldn't want to update the defaults in the code
to sane values?
On Fri, Mar 6, 2009
Jeff Ames wrote:
One nice thing about merge conflicts is that it tells you right away
if a variable you've changed has been modified (e.g., the variable
name changed), so you can correct it immediately instead of wondering
why feature X isn't working any more. But I guess there'd be a lot of
Built-in settings were pretty much abolished because it was found
that it's not possible/feasible to keep them sane.
I think that using an additional OpenSim.ini file is not too steep a
learning curve, and that we should not design to the lowest denominator.
A config override hierarchy is,
Actually, I thought it supported my point very well. ;-)
I was not suggesting that the split ini in config be the only config
option - I still like to override idea. But by default, users would edit
the config/*ini, this does not stop a multi-region grid operator from
syncing 20 override ini
Just splitting up the file and putting it in config, with all the
comments, would help. And for the SVN update - that is a problem
with any modifications to the tree, not just config. That's what
backups are for. I guess a simple backup/diff tool for config would
be a quick solution...
Just
How about splitting to normal ini file and advanced ini file? In the
normal ini file you would have those parameters which 95% of the
people change and rest can be stuffed to advanced ini file.
- Tommi
___
Opensim-dev mailing list
I am one of those people that run trunk and update fairly often on 9
different OpenSim servers. I suspect I always will be. Having to
manually merge two huge ini files, on 9 different servers, is a major
pain. It would be even worse if I had to merge 6 or 8 different medium
sized ini files on
+1 Melanie! ... ... whoa, deja vu! :)
~Sean
Melanie wrote:
And that brings us full circle to my proposal.
There is much sense in a set of files that are used as defaults, and
then overriding settings in specific configuration files.
Melanie
Sean Hennessee wrote:
I am one of those
One nice thing about merge conflicts is that it tells you right away
if a variable you've changed has been modified (e.g., the variable
name changed), so you can correct it immediately instead of wondering
why feature X isn't working any more. But I guess there'd be a lot of
false alarms, if
@lists.berlios.de
Subject: Re: [Opensim-dev] Ini file(s) loading
Melanie wrote:
read [the config directory] first
then read the inimaster
then read the inifile
If I understand this correctly, the config/*.ini files would be
essentially read-only, and all local changes would be made
-Original Message-
From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de] On Behalf Of Jeff Ames
Sent: Thursday, 5 March 2009 7:20 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Ini file(s) loading
Melanie wrote:
read
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Ini file(s) loading
Hi,
Jeff Ames wrote:
Melanie wrote:
read [the config directory] first
then read the inimaster
then read the inifile
This is because the config/* files would hold the defaults, they
must be read first
Melanie wrote:
Hi,
Jeff Ames wrote:
Melanie wrote:
read [the config directory] first
then read the inimaster
then read the inifile
This is because the config/* files would hold the defaults, they
must be read first.
[...]
Then we could break up and move OpenSim.ini.example
available settings user visible.
Adam
-Original Message-
From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de] On Behalf Of Jeff Ames
Sent: Thursday, 5 March 2009 7:20 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Ini file(s
that it can be confusing, especially with the chosen names. So
maybe we do need to rethink that.
--- On Wed, 4/3/09, Sean Hennessee s...@uci.edu wrote:
From: Sean Hennessee s...@uci.edu
Subject: Re: [Opensim-dev] Ini file(s) loading
To: michaelwr...@yahoo.co.uk, opensim-dev@lists.berlios.de
Date
7:20 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Ini file(s) loading
Melanie wrote:
read [the config directory] first
then read the inimaster
then read the inifile
If I understand this correctly, the config/*.ini files would be
essentially read-only, and all local
Yay!! +1
Updating ini files is often a pain. This is an excellent step in the
right direction.
In this scenario, my suggestion/preference would be to have the
bin/config directory contain all the SVN default values, (any number of
files), with NO bin/opensim.ini file present by default. Then
.
But I agree that it can be confusing, especially with the chosen names. So
maybe we do need to rethink that.
--- On Wed, 4/3/09, Sean Hennessee s...@uci.edu wrote:
From: Sean Hennessee s...@uci.edu
Subject: Re: [Opensim-dev] Ini file(s) loading
To: michaelwr...@yahoo.co.uk, opensim-dev
20 matches
Mail list logo
