Version control philosophy and style

Discussion in 'HTML' started by JDS, Jul 14, 2006.

  1. JDS

    JDS Guest

    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, Jul 14, 2006
    #1
    1. Advertising

  2. 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...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)
     
    Richard Levasseur, Jul 14, 2006
    #2
    1. Advertising

  3. JDS

    Chung Leong Guest

    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.
     
    Chung Leong, Jul 15, 2006
    #3
  4. JDS () 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
     
    Malcolm Dew-Jones, Jul 15, 2006
    #4
  5. JDS

    Cloud Burst Guest

    On Fri, 14 Jul 2006 15:55:40 -0400, 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...


    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
     
    Cloud Burst, Jul 15, 2006
    #5
  6. JDS

    JDS Guest

    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
     
    JDS, Jul 21, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rick Miller
    Replies:
    1
    Views:
    494
    Ranagatti
    Sep 19, 2013
  2. tzuchien
    Replies:
    3
    Views:
    1,305
    Gabriel Genellina
    Aug 23, 2007
  3. V Green
    Replies:
    0
    Views:
    862
    V Green
    Feb 5, 2008
  4. PA Bear [MS MVP]
    Replies:
    0
    Views:
    972
    PA Bear [MS MVP]
    Feb 5, 2008
  5. MowGreen [MVP]
    Replies:
    5
    Views:
    2,023
    PA Bear [MS MVP]
    Feb 9, 2008
Loading...

Share This Page