http://www.thenextlayer.org/taxonomy/term/326 The taxonomy view with a depth of 0. en-US http://www.thenextlayer.org/node/426 <p>(please excuse the note form of this article)</p> <p><strong>Background</strong><br /> I am involved in a number of drupal projects, both new and legacy, some as paid projects, some volunteer.<br /> 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.<br /> However, patching and upgrading is a pain, especially over many sites. How could this be managed efficiently and cooperatively?</p> <p><strong>The Solution in general</strong><br /> 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.</p> <p>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.</p> <p><strong>The Solution in more detail (NB. this is not a how-to yet ;)</strong><br /> 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.</p> <p>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.</p> <p>Basically, the drupal core repository will store all of the files, including the core modules EXCEPT anything under the sites/directory.</p> <p>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.</p> <p>To complete the picture we create seperate svn projects for each client instance. these projects will house the following files and directories:</p> <p><code><br /> sites/www.thisparticularone.com/settings.php<br /> sites/www.thisparticularone.com/files<br /> sites/www.thisparticularone.com/modules<br /> sites/www.thisparticularone.com/themes<br /> sites/www.thisparticularone.com/tmp<br /> </code></p> <p>(where <a href="http://www.thisparticularone.com" title="www.thisparticularone.com">www.thisparticularone.com</a> is the base url of each instance - this adheres to the convention of drupal multisite installations and drupal will look here for the files)</p> <p>When we install a new drupal we do it like this:<br /> (NB these commands currently untested as i've changed things a bit since last version)</p> <p><code><br /> #install drupal "core"<br /> svn checkout <a href="https://svn.southspace.org/subversion/drupal/thisparticularone/trunk/" title="https://svn.southspace.org/subversion/drupal/thisparticularone/trunk/">https://svn.southspace.org/subversion/drupal/thisparticularone/trunk/</a> .</p> <p>#add the externals property<br /> svn propedit svn:externals .</p> <p>(which will launch an editor)</p> <p>#add a line like this:<br /> . <a href="https://svn.southspace.org/subversion/drupal/master/trunk/" title="https://svn.southspace.org/subversion/drupal/master/trunk/">https://svn.southspace.org/subversion/drupal/master/trunk/</a><br /> </code></p> <p><code><br /> #get the new items from the external project, ie drupal mater<br /> svn update<br /> </code></p> <p>(to update your drupal including core ie. master project files run)<br /> <code><br /> svn update<br /> </code></p> <p>an ordinary<br /> <code><br /> svn commit<br /> </code><br /> will NOT commit to the external files, ie. the drupal "master". this is what we want ;)</p> <p>though should committ files in /sites/www.thisparticularone.com</p> <p>this is the behavour we want.</p> <p><strong>What i've done already</strong><br /> Installed a xen virtual machine (debian etch) on mediaartprojects.org.uk specificaly for subversion and master instances<br /> Made the repositories available via https<br /> Apache access control only so far<br /> Installed webSVN for viewing repositories (https)<br /> Created master drupal repro, and some "test" projects<br /> Done lots of tests with checking out, setting externals property updating etc using master and projects</p> <p>refs:<br /> Subversion Manual<br /> <a href="http://svnbook.red-bean.com/" title="http://svnbook.red-bean.com/">http://svnbook.red-bean.com/</a><br /> <a href="http://svnbook.red-bean.com/en/1.1/ch07s04.html" title="http://svnbook.red-bean.com/en/1.1/ch07s04.html">http://svnbook.red-bean.com/en/1.1/ch07s04.html</a><br /> <a href="http://drupal.org/node/53705" title="http://drupal.org/node/53705">http://drupal.org/node/53705</a><br /> <a href="http://agaricdesign.com/note/agaric-wants-version-control-lets-drupal-core-and-contrib-replace-entire-directories-within-our-checkouts" title="http://agaricdesign.com/note/agaric-wants-version-control-lets-drupal-core-and-contrib-replace-entire-directories-within-our-checkouts">http://agaricdesign.com/note/agaric-wants-version-control-lets-drupal-co...</a></p> <p>i'm not the only one working on this, by the way ;)</p> http://www.thenextlayer.org/node/426#comments English Article London Drupal FLOSS methods subversion taxi-to-praxi tools Wed, 16 Apr 2008 15:09:27 +0200 lisa 426 at http://www.thenextlayer.org