Version control philosophy and style

[JDS]

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

 

[Richard Levasseur]

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

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

http://groups.google.com/group/comp...fc0861b30517c?q=ideal&rnum=1#e2ffc0861b30517c

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)

 

[Chung Leong]

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.

 

[Malcolm Dew-Jones]

JDS ([email protected]) wrote:

: 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?

I just keep separate config files for the different servers. Install the
app, and then install the appropriate config. I don't see how to avoid
"tweaking" the different config files at some point.

The development copy becomes your defacto "master" version. Note that the
versioning of this copy will track _two_ kinds of changes. "Maintence"
changes required for the (developmenet) server, and "upgrade" changes
required for the application updates.

Make sure that only one type of change is checked in at a time. E.g. if
you add a config variable (an upgrade change) and also change a path (a
maintenance change) then do two checkins, once to add the config variable
and once to change the path.

That way, later on it is easier to replicate the "upgrade" changes, simply
do a diff between the before and afters of the "upgrade" checkins.

Then apply those same changes to the various server configs.

If you get ambitious then use those changes as patches to automate the
upgrades of the server-specific configs. Apply the patches (in my example
to add the config variable), and then tweak the new values for each server
config (which you have to do at some point anyway).


Or - replace this whole thing with an install utility. That may itself
need a config file, but it will likely be simpler to maintain as you can
allow all sorts of defaults that the install will detect itself.

Or - a variation - use paths and variables in your development version
that are carefully chosen to be unambiguous in your code, and then a
script can easily _edit_ the master config file during the install to have
server specific values.

Or - include a config upgrade script with your application that will read
the old config variables and then spit out a new config file using those
values, perhaps prompting for any values that are new and cannot be
calculated.

$0.10

 

[Cloud Burst]

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

 

[JDS]

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