Hi all,
Another mechanism that I have used in the past with fairly good results
is too utilize the capabilities of ANT (although I guess this really
applies to Java based sites) to produce a build of the webapp
configuring the properties appropriate for the given target.
Thus we have a set of configuration files that are for a particular
target, ie.
Logging.properties
Logging.UAT.properties
Logging.QC.properties
Logging.INT.properties
Logging.PROD.properties
The default Logging.properties applies to the development environment
and you can use ANT to copy / replace the Logging.properties from the
appropriate Logging.XXX.properties file for the given target.
Of course ANT provides a number of more sophisticated options to manage
this, but I have found that this provides a good balance between
flexibility and the time spent to manage the properties for each
individual target and some other mechanism that would programmatically
handle this case.
Whatty
-----Original Message-----
From: Andy Levy [mailto:andy.levy@gmail.com]
Sent: Monday, January 29, 2007 1:45 PM
To: Cliff Haithcock
Cc: users@subversion.tigris.org
Subject: Re: Subversion for websites
On 1/29/07, Cliff Haithcock <cliff@rasantiago.com> wrote:
>
> Hi all,
>
> I reviewed the FAQ and searched through the archives for info on using
> Subversion to manage website development. I could not find an answer
to
> the following situation.
>
> We have a production db server, staging db server, and development db
> servers for our developers. We plan to have developers checkout from
the
> trunk and set the staging and production environments to serve from
> checked out tags.
>
> Within each of the three development environments, we modify the db
> connection script to point to the proper db server.
>
> We are looking for a best practices solution for how to manage a file
in
> svn that our current setup requires to be different upon the usage of
> the checked out code.
>
> Do we pull the one db connection script out of svn and manage it
> manually? Or is there some clever way to drive svn to solve our
problem?
> Or should we make our connection script smart enough to know which db
> server it should connect to (we aren't exactly sure how to do this,
but
> will consider it)?
The last is the option I always opt for. That or a configuration file
specific to each environment, which is loaded based on code detecting
the environment it's running in. This way, I can be certain that I am
always moving the exact same code into each environment.
IOW, I don't want to change *anything* when I move my application from
one environment to the next. It should be smart enough to detect
where it's running, and how it should configure itself.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 29 20:01:13 2007