[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Subversion for websites

From: Steven Whatmore <Stevenw_at_sigmasoft.ca>
Date: 2007-01-29 20:00:22 CET

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.


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.


-----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
> 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
> 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
> 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
> 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,
> 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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.