I have a Perl script that wrote just for situations like this. It's an
auto-configuration utility. Basically, any file that needs
configuration will be a template file. The script goes through the
directory structure looking for these template files, fills in any
macros with their correct values, and writes out the configuration
files.
The nice thing is that there is a very basic "programming language"
that is embedded as comments into your configuration templates. These
prompt the person installing the software for information such as IP
addresses, domain names, email addresses, or almost anything that may
need to be set. Once the setup is complete and the configuration files
are generated, an "answer file" stores the user's answers. That way,
when you do an upgrade, and the system already knows the answer, it
skips over the question.
I created this because of this type of situation: Hundreds of
customers and each customer had their own configuration. Plus, our
developers and testers also had their own configuration for their
machines. This program greatly simplified upgrades and installation
for us.
Even better, if a new parameter was needed during an upgrade, the
system would realize it doesn't know the answer to that question and
prompt the user.
Give it a try and see if it helps you in your situation. It's
available from http://dl.getdropbox.com/u/433257/autoconfig.pl. Feel
free to ping me if you need any help with it.
On Thu, Feb 26, 2009 at 1:35 PM, <blackhole_at_collab.net> wrote:
> Thanks David,
> A deploy script is not a good solution in this scenario.
> Say I have 50 websites using web.ini. I create the websites and modify each web.ini to suit each individual site. Now, a new parameter is added to web.ini. At the moment I would have to edit each web.ini file in all 50 sites.
> It would be practical if I could do a svn update in each site and bring in the parameter (with a standard value) in each site. That make sense.
>
> The above would require the web.ini to be part of the repsotiory, however, in the sandbox, the web.ini in each site cannot be commited! Since that would overwrite all default values in the repository.
>
> In short, it would be nice if there was a feature where one could exclude files from commits, but allow them to be updated. That way, if a parameter is added to a ini file, all ini files (at production) could be updated with this new addition. Running a deploy script only works for something that never will get additions. If there are anticipated additions to a file, having them outside the repository is not a good solution since it will require someone to manually bring in the additions.. if we are talking about50 sites it could be done, but what about if we have 500?
>
> Maybe the above solution is already there?
> Is it?
>
> I'm not an advanced svn user (yet) :)
>
> Thanks,
> totte
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1234212
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
>
--
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1235459
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-27 00:35:01 CET