Here is how I upgrade my Drupal sites (which have their own customizations) to new versions of drupal core when they become available, as I mentioned in a previous post.
This section of the subversion book pretty much explains it. Here is specifically what I did for Drupal, assuming you already have some directories set up as follows:
/var/svn/repos/www/vendor/drupalcore /var/svn/repos/www/vendor/drupalcore/4.7.2 /var/svn/repos/www/vendor/drupalcore/4.7.3 /var/svn/repos/www/vendor/drupalcore/4.7.4 /var/svn/repos/www/vendor/drupalcore/current /var/svn/repos/www/drupal4.7
/var/svn/repos/www/drupal4.7 is like my own drupal4.7 "trunk". The
/var/svn/repos/www/vendor/drupalcore is where I track all the vendor sources.
Download the new drupal sources:
cd ~/downloads wget <a href="http://ftp.osuosl.org/pub/drupal/files/projects/drupal-4.7.5.tar.gz
svn_load_dirs to load the new sources into current and create a tag of current called 4.7.5:
svn_load_dirs file:///var/svn/repos/www/vendor/drupalcore current ~/downloads/drupal-4.7.5 -t 4.7.5
Now go to a checked-out copy of
cd /var/www/localhost/htdocs/sandbox svn st svn ci -m "commit some uncommitted changes that I had (might as well get these in)"
Merge in the changes between 4.7.4 and 4.7.5. This is the magic (almost as magical as svn-load-dirs):
svn merge file:///var/svn/repos/www/vendor/drupalcore/4.7.4 file:///var/svn/repos/www/vendor/drupalcore/current .
Now you will see a bunch of output similar to what you would get if you did an update. Look through the changes with
svn diff |less. Especially the changelog, just to make sure you are actually upgrading from 4.7.4 4.7.5 and not something different (due to a typo in the previous svn commands above).
Make sure to test the codebase first. I backed up my database first, then went to
<a href="http://localhost/update.php">http://localhost/update.php[/geshifilter-code] and made sure the upgrade worked. Very important step!
Commit it when you are happy:
svn ci -m "Merged differences between drupal core 4.7.4 and 4.7.5"
After this I logged in to my 3 drupal sites, backed up the db, ran
svn up, ran
<a href="http://localhost/update.php">http://localhost/update.php[/geshifilter-code], and checked that there were no errors and that the site loaded some pages with no trouble. If I notice a problem in a few days I can always revert to the database backup I made.
That's all there is to it to upgrade a Drupal site when a new Drupal tarball is released! As long as you track vendor sources in your own subversion repository, the rest is easy.
The advantage of this technique is that I can make changes to drupal core but I can still easily merge in changes from new drupal releases. I can also do this same thing with modules. I track the module sources in a directory structure like:
/var/svn/repos/www/vendor/drupalmodules/gmap /var/svn/repos/www/vendor/drupalmodules/gmap/09_09_2006 /var/svn/repos/www/vendor/drupalmodules/gmap/10_24_2006 /var/svn/repos/www/vendor/drupalmodules/gmap/10_25_2006 /var/svn/repos/www/vendor/drupalmodules/gmap/current /var/svn/repos/www/vendor/drupalmodules/flash_gallery /var/svn/repos/www/vendor/drupalmodules/flash_gallery/11_01_2006 /var/svn/repos/www/vendor/drupalmodules/flash_gallery/current /var/svn/repos/www/vendor/drupalmodules/location /var/svn/repos/www/vendor/drupalmodules/location/10_20_2006 /var/svn/repos/www/vendor/drupalmodules/location/current
I made some changes to the gmap and location module. I have had to merge in upstream changes in the gmap module 3 times. You can perform the merge by providing the location of the old tag and the new tag (or just use current) and the destination of the merge is a working directory of the module in question's directory (within the drupal modules directory of your trunk).
I have also used this technique several times for the mediawiki site at work. I highly recommend doing this any time you modify upstream source code and want to get updates from upstream when they become available.