Child pages
  • LauingerDrupalSubversion
Skip to end of metadata
Go to start of metadata

Working proposal for placing Lauinger Drupal site under Subversion source control


  • Put Drupal code and configuration under version control for purposes of configuration change management.
    • This excludes content and "data" and certain bits of configuration, which is specific to a site
  • Facilitates keeping the development, test and production servers in sync.
  • Serves as an implicit record of what different constellation of modules and themes (and versions of same), as well as configuration parameters are in use on the site at a given point in time
  • As an additional benefit, also implicitly facilitates management of custom code changes to modules and themes, of which we have a few examples already
  • Provides a more deterministic process for making changes and having confidence that what is deployed is what was intended, with a lesser chance of human error
  • Increases ability to replicate a specific set of changes
  • Easier to roll back the site to an earlier version if problems are discovered.


  • Drupal site will essentially run directly from a checked-out Subversion working copy
  • Subversion repository will be hosted on existing UIS Subversion server (

Drupal filesystem reorganization

  • Directories to be re-organized to make management easier for the files under version control.
    • /var/www/apps/drupal.
      • New top-level directory
      • This is the the root dir of a checked out Subversion working copy
    • 2 subdirectories effectively under version control
      • /var/www/apps/drupal/drupal-app
        • Drupal core application.
        • Corresponds to what is currently e.g. /var/www/apps/drupal-6.19
      • /var/www/apps/drupal/drupal-data
        • Drupal local site customization (modules, themes) and site configuration (e.g. .htaccess, settings.php) minus sensitive data not under version control (e.g. passwords).
        • Corresponds to what is currently /var/www/apps/drupal-data.
    • 2 subdirectories excluded from version control via svn:ignore:
      • /var/www/apps/drupal/drupal-files
        • File data stored in filesystem and managed by Apache.
        • Corresponds to what is currently /var/www/apps/drupal-data/sites/<site name>/files
      • /var/www/apps/drupal/drupal-etc
        • Configuration data that should not appear in version control because is either sensitive or is server-specific, e.g. passwords.
        • Corresponds to what is currently the database username/password data stored within settings.php
  • Data located in /var/www/apps/drupal/drupal-etc is logically included into the configuration by use of PHP include directories. Example settings.php contains:
    settings.php snippet
    include '/var/www/apps/drupal/drupal-etc/settings-default.php'
  • File data within /var/www/apps/drupal/drupal-files is logically included into the filesystem by use of symbolic links in the corresponding places within the 'sites' structure, for example:
    /var/www/apps/drupal/drupal-data/sites/default/files ->  ../../../drupal-files/default/
    • Use relative paths so links will not break if directory structure is re-organized.
    • Subversion automatically manages symbolic links as to committing them and checking them out.

Subversion repository layout

  • The repository (e.g. "lauinger-drupal") will contain an area for the management of the site under version control (e.g. "site")
  • The site area will contain the standard trunk/branches/tags structure, e.g.
    • /lauinger-drupal/site/trunk
      • Used for the main line of development for what is intended to go to production
    • /lauinger-drupal/site/branches
      • Can be used for trying out new modules or other experimental/exploratory work, prior to actually deciding to put them into the main development line.
    • /lauinger-drupal/site/tags
      • Used to give logical tags/names for different categories for the site in the development and deployment process, such as:
        • Versions of the site actually deployed in production
        • Milestone versions of the site created during the development, before a final production tag is created
        • Anything which requires a logical name for a particular version of the site at a particular point in time


  • Make sure to not allow .svn directories to appear in web view

Issues to look at further

  • Decide upon a structure and consistent naming convention for branches and tags
    • Might be desirable to have additional levels in the tree underneath /tags and /branches
  • Work out technical procedures for common tasks:
    • Core upgrade
    • Module/theme - new installations
    • Module/theme - upgrade existing version
    • Tagging a production version
    • Deploying a production version
  • Bringing in updates, 2 fundamental approaches:
    • Use a variation on the common methodology of maintaining a vendor branch + 3-way merges
    • Use an intelligent process, probably a script, to manage recursively copying the updated source into the working copy and taking the appropriate action with 'svn' commands for the cases of adds, updates, and removes
  • Standard Subversion commands can always be used, but some common tasks could be facilitated via task-specific scripts
  • Update current snapshot creation and unpacking scripts to take new filesystem layout and version control process into account
    • No longer include code in the snapshot; only database and filesystem data, plus a pointer to the path and revision of the deployed site ('svn info') at the point-in-time of the snapshot
  • No labels