Subversion/Drupal distributed multisite project

lisa — Wed, 16 Apr 2008 13:09:27 +0000

English

(please excuse the note form of this article)

Background
I am involved in a number of drupal projects, both new and legacy, some as paid projects, some volunteer.
I am involved or want to help with the maintainence of the code base (security patching, upgrades etc). However not all of the projects are on my own server. And as I am not a hosting company that is how things should be.
However, patching and upgrading is a pain, especially over many sites. How could this be managed efficiently and cooperatively?

The Solution in general
Make a designated server for subversion. Create a "master" drupal instance that is not actually used to publish anything, and from this create a subversion repository that will house the drupal "core" codebase, AND a seperate but related repository that can house the files specific to each drupal instance. Install each drupal instance that is to be maintained in this way via svn checkout on their own server, wherever it is. Lets call these drupal instances client instances.

When patches and upgrades come out, do these on the master instance and commit the changes to the repository to create a new revision. To upgrade each client instance simply run svn update on each server, possibly followed by running the drupal update.php script.

The Solution in more detail (NB. this is not a how-to yet ;)
We need to adhere to the conventions of drupal multisite installations to make this work nicely, even though the sites are most probably on different servers so this is not actually a multisite installation.

As we need to combine two code projects (the drupal core files and the files specific to each client instance) to create each instance, we make use of the svn:externals property. The master drupal files will be "external" to the domain specific files.

Basically, the drupal core repository will store all of the files, including the core modules EXCEPT anything under the sites/directory.

The sites/ directory is EXCLUDED from the drupal core repository, except for sites/all/modules, where we can keep modules that are NOT core but are used in pretty much every client.

To complete the picture we create seperate svn projects for each client instance. these projects will house the following files and directories:

sites/www.thisparticularone.com/settings.php sites/www.thisparticularone.com/files sites/www.thisparticularone.com/modules sites/www.thisparticularone.com/themes sites/www.thisparticularone.com/tmp

(where www.thisparticularone.com is the base url of each instance - this adheres to the convention of drupal multisite installations and drupal will look here for the files)

When we install a new drupal we do it like this:
(NB these commands currently untested as i've changed things a bit since last version)

#install drupal "core" svn checkout https://svn.southspace.org/subversion/drupal/thisparticularone/trunk/ .

#add the externals property
svn propedit svn:externals .

(which will launch an editor)

#add a line like this:
. https://svn.southspace.org/subversion/drupal/master/trunk/

#get the new items from the external project, ie drupal mater svn update

(to update your drupal including core ie. master project files run)
svn update

an ordinary
svn commit
will NOT commit to the external files, ie. the drupal "master". this is what we want ;)

though should committ files in /sites/www.thisparticularone.com

this is the behavour we want.

What i've done already
Installed a xen virtual machine (debian etch) on mediaartprojects.org.uk specificaly for subversion and master instances
Made the repositories available via https
Apache access control only so far
Installed webSVN for viewing repositories (https)
Created master drupal repro, and some "test" projects
Done lots of tests with checking out, setting externals property updating etc using master and projects

refs:
Subversion Manual
http://svnbook.red-bean.com/
http://svnbook.red-bean.com/en/1.1/ch07s04.html
http://drupal.org/node/53705
http://agaricdesign.com/note/agaric-wants-version-control-lets-drupal-co...

i'm not the only one working on this, by the way ;)

Subversion, a useful FOSS tool

lisa — Wed, 16 Apr 2008 13:03:02 +0000

English

I have had to use subversion recently for a job, which is great as i've been meaning to start using it for ages! Here is an intro to subversion, and following a suggestion of how it could help next layer and related projects in a very practical way.

---

Subversion is a "versioning system" that is used most often by coders and documentors to store text files, but can actually be used for any kind of data.

Its a key tool for collaboration, allowing people to "checkout" a "working copy" of the shared files, modify, add and delete content and/or files on them wherever or however they wish, then "commit" them back to the "repository". If other people have been working on the same code the changes can be "merged" together, a process that would be part manual and part automated, depending on the extent of the changes.

subversion remembers every version that was ever committed, and can give you information about who submitted what revision, and even give you a line by line listing of who changed what when with the "blame" command. It uses the unix utility "diff" to generate information about the precise differences between one version and another, at the level of the file contents and/or the file system structure.

(note: terms in inverted commas are technical terms with specific meaning in subversion and indeed other version control systems )

Version control systems in general
http://en.wikipedia.org/wiki/Version_control_system
Subversion FAQ
http://subversion.tigris.org/faq.html
Subversion Manual
http://svnbook.red-bean.com/

lisa's blog

Subversion/Drupal distributed multisite project

Subversion, a useful FOSS tool