[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion on Drupal

From: Geoff Hoffman <ghoffman_at_cardinalpath.com>
Date: Thu, 11 Aug 2011 20:14:42 -0700

On Thu, Aug 11, 2011 at 7:56 PM, Andy Canfield <andy.canfield_at_pimco.mobi>wrote:

> My goal in learning Subversion was to put our web site under version
> control. Now I have my doubts as to whether Subversion can handle it.
>
> The web site uses Drupal. And Drupal has the characteristic that much of
> the site is contained in a MySQL database. For example, if I install a
> module and set it up, the module is a disk file, but the configuration of
> that module is in the database. If I make a change, part of the change may
> be in a PHP code file on disk, part may be in the database. The database
> contains both user data and configuration data, intermingled.
>
> I could get Subversion to work. I would have a pre-commit script to back up
> the database to a disk file in the working copy. I would have a
> post-checkout script to reload the database from the disk file. Along with
> svn commit and svn checkout, this would give us the ability to roll back to
> any earlier version.
>
> What I can not imagine is how to get more than one person to be able to
> work on the site. Yes, Subversion would be able to merge changes to the disk
> files. But I don't see how Subversion can handle merging changes to the
> database. The MySQL database is text; perhaps someone here as experience
> with that. Can MySQL backup files be merged?
>
>

You'll need to analyze your app closely do it right, but it's absolutely
possible.

It's a daunting task for Drupal, WordPress, Joomla or any other CMS-driven
site and everyone who manages these type of sites deals with the issue
differently.

Subversion can handle whatever you svn commit. That's not the problem at
all. The filesystem files that make up your Drupal install are easy to
manage. You'll need to use svn:ignore on the uploads directory, cache, logs,
etc., but that's the easy part.

The tricky part is managing database schema under version control, and there
are myriad ways to output your db schema to a text file or files, try
phpMyAdmin for starters.

You have to plan your version control system to account for and
differentiate between dynamic/user-generated content in the database that it
needs to ignore, versus that which plays a critical role in the ui such as
dropdown items in forms.

You don't want your client's website content in your version control system
if you can avoid it, and with one well-written backup script you can achieve
it.

It goes without saying that you'll need at least one VM or additional
hosting account, virtual host on your server or other technique to develop
and/or stage your planned changes, too.
Received on 2011-08-12 05:15:28 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.