I am trying to figure out how to use Subversion, but this question isn't
really Subversion-specific. Any version control system will suffer from
the same problem, IMO.

I've crossposted to those groups I've deemed most relevant WRT web
development. (Well, relevant to *me*). I don't think this question will
be completely relevant in a C/C++ or other local devlopment environment.
Maybe it is...


So, in using Subversion, I have imported a webapp directory tree "into"
Subversion.

I have then "checked out" a copy of the webapp into a development
directory. (This is a PHP+Apache+MySQL app, btw).

Now, to test, I have a LAMP environment installed *locally* and I access
the webapp locally (the cheked out copy) using
http://localhost/path/to/webapp/


Now, the question comes down to configuration details and "pushing" the
thing to the live web server. The local LAMP config and the "live" SAMP
config (the live server is on Solaris) are quite different from each other
as far as naming of paths and whatnot on the server.

There *is* a config file in the webapp hiearchy! Changing that file
easily makes the webapp point all of its various pieces to the correct
paths and files on the server.

But the config file has to be different on the working copy than on the
server!

How can a version control system deal with this problem without me having
to tweak the "live" config file every time I migrate the app from the
Subversion repository to the live server?

Any general insight at all would be appreciated. I have worked as a web
developer for quite a while now, but never have used a VCS before. I'm
sure it is not a new question! But how does one Google on so esoteric a
concept?

Allright, thanks. later...

--
JDS

JDS wrote:
> I am trying to figure out how to use Subversion, but this question isn't
> really Subversion-specific. Any version control system will suffer from
> the same problem, IMO.
>
> I've crossposted to those groups I've deemed most relevant WRT web
> development. (Well, relevant to *me*). I don't think this question will
> be completely relevant in a C/C++ or other local devlopment environment.
> Maybe it is...
>
>
> So, in using Subversion, I have imported a webapp directory tree "into"
> Subversion.
>
> I have then "checked out" a copy of the webapp into a development
> directory. (This is a PHP+Apache+MySQL app, btw).
>
> Now, to test, I have a LAMP environment installed *locally* and I access
> the webapp locally (the cheked out copy) using
> http://localhost/path/to/webapp/
>
>
> Now, the question comes down to configuration details and "pushing" the
> thing to the live web server. The local LAMP config and the "live" SAMP
> config (the live server is on Solaris) are quite different from each other
> as far as naming of paths and whatnot on the server.
>
> There *is* a config file in the webapp hiearchy! Changing that file
> easily makes the webapp point all of its various pieces to the correct
> paths and files on the server.
>
> But the config file has to be different on the working copy than on the
> server!
>
> How can a version control system deal with this problem without me having
> to tweak the "live" config file every time I migrate the app from the
> Subversion repository to the live server?
>
> Any general insight at all would be appreciated. I have worked as a web
> developer for quite a while now, but never have used a VCS before. I'm
> sure it is not a new question! But how does one Google on so esoteric a
> concept?
>
> Allright, thanks. later...
>
> --
> JDS

I posted how I deal with this a little while back:

http://groups.google.com/group/comp....ffc0861b30517c

Right now i simply delete the whole live site and export a clean copy
of it from subversion (phpmyadmin, bugzilla, wiki, etc are stored in a
directory aboved and aliased to prevent deletion). In addition to the
export, i delete certain files: *.dev.php, and *.config-dev.php (in
case i forget to). This allows me to automatically update the
development server on each commit (using a hook) then roll it out to
the live one without worrying about having to change configuration
settings.

In retrospect, I probably should have made the live version a working
copy, too, so i could just do an update and use svn:ignore to filter
out the development files.

The downside is that the working config file is versioned, when it
should just be the vanilla configuration file that is versioned. It
would be better to take an approach like phpmyadmin: have a versioned
vanilla default.config.php, then an overridding, non-versioned file
server.config.php that is included if it exists. Then you can update
the defaults and keep them in sync with the latest version while not
losing your custom settings.


Another approach i just thought of would be to use svn's merging
abilities, but have it always use your copy instead of their copy.
That way, when it merges and there's a conflict, your custom settings
will take precedence. The downside of this is that if you make a small
patch to the live site then you'll have to manually update that file
(so that your HEAD version's fixes go in over the temporary patch)

JDS wrote:
> But the config file has to be different on the working copy than on the
> server!
>
> How can a version control system deal with this problem without me having
> to tweak the "live" config file every time I migrate the app from the
> Subversion repository to the live server?

The easy answer is to simply not version control the config file. But
that's not a satisfactory answer, as there are clear benefits in
keeping the file in the repository. It remembers the date when you
change the config and give you a place to enter a reason explaining the
change. That could be very useful information when odd things start to
happen. The ability to roll back to a previous configuration is
obviously a big plus. Having the file under SVN also simplifies the
push process.

One possible strategy is to have separate config files under different
names. Depending on which environment the application is running in,
it'd load in the correct one. For example:

$conf = parse_ini_file("{$_SERVER['SERVER_NAME']}.ini", true);

I would keep both the production and the development version in SVN.
That way you wouldn't forget that a config change is necessary for some
newly developed code, since SVN will spot the change when you commit.

On Fri, 14 Jul 2006 15:55:40 -0400, JDS <jeffrey@invalid.address> wrote:

>I am trying to figure out how to use Subversion, but this question isn't
>really Subversion-specific. Any version control system will suffer from
>the same problem, IMO.
>
>I've crossposted to those groups I've deemed most relevant WRT web
>development. (Well, relevant to *me*). I don't think this question will
>be completely relevant in a C/C++ or other local devlopment environment.
>Maybe it is...
>
>
>So, in using Subversion, I have imported a webapp directory tree "into"
>Subversion.
>
>I have then "checked out" a copy of the webapp into a development
>directory. (This is a PHP+Apache+MySQL app, btw).
>
>Now, to test, I have a LAMP environment installed *locally* and I access
>the webapp locally (the cheked out copy) using
>http://localhost/path/to/webapp/
>
>
>Now, the question comes down to configuration details and "pushing" the
>thing to the live web server. The local LAMP config and the "live" SAMP
>config (the live server is on Solaris) are quite different from each other
>as far as naming of paths and whatnot on the server.
>
>There *is* a config file in the webapp hiearchy! Changing that file
>easily makes the webapp point all of its various pieces to the correct
>paths and files on the server.
>
>But the config file has to be different on the working copy than on the
>server!
>
>How can a version control system deal with this problem without me having
>to tweak the "live" config file every time I migrate the app from the
>Subversion repository to the live server?
>
>Any general insight at all would be appreciated. I have worked as a web
>developer for quite a while now, but never have used a VCS before. I'm
>sure it is not a new question! But how does one Google on so esoteric a
>concept?
>
>Allright, thanks. later...

How about:

1. Check in the config file with replaceable parameters instead of
whatever values you have to change for local/testing compared with
server/production values.

2. Then use a little ed or perl script to change the replaceable
values as needed each time you test or deploy.

3. The ed or perl script should also be checked in, so everything
is tidy.

HTH.

CB

On Fri, 14 Jul 2006 17:20:49 -0700, Chung Leong wrote:

> One possible strategy is to have separate config files under different
> names. Depending on which environment the application is running in,
> it'd load in the correct one. For example:
>
> $conf = parse_ini_file("{$_SERVER['SERVER_NAME']}.ini", true);
>
> I would keep both the production and the development version in SVN.
> That way you wouldn't forget that a config change is necessary for some
> newly developed code, since SVN will spot the change when you commit.

Thanks, all, for the insightful input.

I have opted for Chung's suggestion, as it feels best to me. The other
suggestions were all great as well!

So now, for the config, I have a static file that has non-environment
specific config details, and it includes a server-specific file based on
$_SERVER['SERVER_NAME'] for the server-specific stuff.

All configs are versioned, of course.

Allright, I think I'm starting to get the hang of using version control!
Later...

--
JDS