Advantage Labs

The Advantage Labs, Inc. managed Drupal repository is available for public checkout and browsing.

You can browse the repository online at or you can check it out using your Subversion client of choice. To check out the SVN repostitory, point your client to:

http://svn.advantagelabs.com/managed

The managed repository has the following basic structure:

• drupal—this directory contains the imported drupal core files
  • branches—contains the Drupal.org official branches (e.g. drupal-5, drupal-4-7). This allows core files and modules to be grouped by major drupal versions.
    • drupal-5—a branch for drupal core files, modules, profiles, and other data all relating to the drupal-5 release
      • drupal—contains the drupal core distribution
      • profiles—contains drupal installation profiles. Profiles can pull in managed modules and configure databases.
      • sites—a directory for specific websites as well as common modules in the ‘all’ directory.
        • all—these modules are shared across all installed sites. They are not actually in the repository here, but instead svn:externals point to specific vendor branches in the /vendor directory.
        • skel—the skeleton site directory we use to create new sites on the managed build. It can contain custom themes, modules, and filestags—should we need to tag a specific revision in the repo, this directory will hold the copy
  • tags—should we need to tag a specific revision in the repo, this directory will hold the copy
    vendor—this directory contains vendor branches of drupal core, drupal contributed modules, and other 3rd party software (e.g. the Moxiecode TinyMCE editor).
• vendor—this directory contains vendor branches of drupal core, drupal contributed modules, and other 3rd party software (e.g. the Moxiecode TinyMCE editor).

A note on vendor branches: This repository makes heavy use of SVN vendor branching. For each project in the vendor branch, a ‘current’ directory is created. As new releases are added, the current directory is updated and a copy is made to “tag” it with it’s release information. For example, see the views module . This module has several releases tagged and a single current directory.

To pull these tagged revisions into specific places in the directory tree (for example in sites/all), svn:externals properties are pointed to specific tags. This allows a single codebase to serve many needs. Sites can point to specific revision tags, if they are unable to upgrade to the latest version of the module, and changes, such as adding new code to the branch, do not change the common installation until the svn:externals are updated and tested.