HOWTO: Upgrade an SVN Managed Drupal Installation (without CVS)
Tags :
At Chapter Three we use the Subversion Version Control System to manage our client and internal Drupal projects. When we kick off a new project we roll out the latest version of Drupal, stick it in the SVN repository, and start developing.
As a matter of best practices it is usually a good idea to check Drupal directly out of the Drupal CVS repository which makes upgrading as simple as "cvs update -dP -r DRUPAL-5--X". However, we have a number of sites that were not checked out in this way and this makes updating Drupal sort of a pain. Our SVN management system wants us to update each file individually (so the changes can be versioned), but individually updating each of Drupal core's 300+ files is a little bit tedious.
However, with a little command line wizardry we can quickly download a copy of Drupal and generate a command to copy the new version of each Drupal core file on top of our installation in a way that can be committed up to SVN. To do this we need to wget a copy of Drupal and then use the all powerful find command to detect and copy the relevant files.
wget http://ftp.drupal.org/files/projects/drupal-5.9.tar.gz
gzip -d drupal-5.9.tar.gz
tar xf drupal-5.9.tar
cd drupal-5.9
# Use Find to Detect Each Local File in Drupal Core and Execute a
# Command to Copy the File to the Live Version of the Website
find * -type f -exec echo cp {} /path/to/www/{} \; # this just echos the commands
find * -type f -exec cp {} /path/to/www/{} \; # this actually runs the commands
To make sure the copy worked we can use the same find command do an individual diff on each file. This will assure us that we successfully updated our website with the version of code we downloaded from Drupal. This command can also be used prior to updating to compare different versions of Drupal to see what core changes are going to be (or have been) made.
find * -type f -exec diff {} /path/to/www/{} \;Comments
Post a comment
Presentations
What we've coded
Videos
Upcoming workshops
-
San Francisco, CAFebruary 28, 2012
-
Denver, COMarch 19, 2012
-
Denver, COMarch 19, 2012
When I run this find command, it seems to take all the new files and copies them into the main drupal directory of the existing installation, not into the subdirectories, so you end up with everything in /path/to/www, no matter what subdirectory it came from.
Make sure you have the after /path/to/www/, or you will indeed end up with everything in one folder.
I suspect that different shells handle this differently. I use bash for my updates and that seems to work. Try running the script in bash.
I've previously only done Drupal upgrades on a PC where dragging the new files and folders over to the existing working copy preserves all the .svn directories and only replaces changed files.
Now I'm developing on my Mac, and finder insists on deleting my .svn directories instead of performing a merge.
Your tip works around this problem perfectly, and is a lot faster than doing it in the GUI anyway.
I know this comment is 2 years old, but to merge on a mac try the ditto command in the terminal.
ditto Folder1 Folder2
This will not replace, only overwrite.
Good article, Matt.
Just one suggestion/question:
Why not use 'tar xfz' to gunzip and untar the archive, instead of calling gzip and tar separately?
There is no worries to use tar xfz in the command. I was trying to be a little more specific with everything (first you unzip, then you untar). It works just as well the other way of course.
if you perform a cp of every frile from the downloaded site to your existing site, won't you overwrite your existing site files no questions asked?
i guess if you don't modify core, that's ok. but if for some reason you did, it would overwrite your changes.
and if something went wrong for whatever reason you'd be screwed if you didn't back up your existing site. you couldn't backout and get back to where you were before. so you probably should mention doing a backup in your post.
finally. i imagine the aim of this post is so that you can convert a NON CVS existing site into a CVS based one that you check back into svn. but when you download and extract a drupal tar file it does NOT have the CVS directories in it right? at least that's been my experience. so wouldn't you do a CVS checkout instead of the wget / tar operation listed in the post? otherwise your existing site will never be under CVS control (e.g. have the ncessary CVS metadata directories included). or am i missing something?
last but not least. after your existing site is updated to CVS you then have to check it back into SVN as an svn project. so it would be nice to see a followup post on how you get the drupal CVS source into svn, how you perform updates to the svn check'd out drupal site / src using CVS, and how you perform regular updates and VERSIONING/TRACKING (e.g. tags) to svn as you make daily fixes to the drupal svn site.
the whole CVS inside of svn is sort of double work. since it sounds like you use this on a regular basis it'd be a great idea for a post if you guys can swing it.
thanks
you are copying a fresh download of drupal into the existing site. so i imagine that means you're
Hi Guys,
Interesting article. We had the same problem, but I think I may have found a good solution to get older projects working with CVS.
We have a number of Drupal sites in our subversion repository but without CVS info in them.
I decided to a fix these older projects. Method I used was...
1. Download the same version of Drupal via CVS to a separate folder.
2. Use rsync to copy the CVS info over to the Drupal in my subversion working copy.
3. Test the new merged CVS and subversion files on my local working copy. As long as your not hacking core, which we are not, there was no probs.
4. Add and commit changes.
5. Issue csv update command to update to new version.
All worked fine.
Good work! Your post/article is an excellent example of why I keep comming back to read your excellent quality content that is forever updated. Thank you!
This works alright, but it doesn't handle new subdirectories that don't exist in the local copy and it doesn't delete files and folders that no longer exist.
Those events don't come up in a drupal point-release update. This procedure is not for going from v6 to v7, but rather for security updates and the like.
As a few comments above mentioned, there are a few problems with this. a) files that are removed from a new release are not deleted and b) changes made to the existing drupal files are not preserved. Check out my guide to maintaining vendor sources with subversion (with drupal example) for an alternative method that solves this issues and makes upgrading a breeze.
Also, check out my script to easily upgrade drupal modules.
The way I handle my projects (using SVN and on a Mac) is by getting the latest module or core from Drupal and then I diff and update the new files against and updated working version of the modules or core directories:
ditto -V download/dir/module_dir_name all/modules/module_dire_name
Compares the new version of all the files, and directories and updates the local working copies accordingly (without erasing .svn files - Mac OS is notorious for that). I then checking the updates to the central repo for all modules.
In my case, all sites share the same modules (activating only those needed per site) and so once the updates is in SVN, I can update to a staging area and test the updates before tagging the changes in SVN and then using svn switch to update the live site.
Assembling core, modules, site-specific files
Needless to say, I need a unique copy of each core version in SVN and simply svn switch each site to the latest thus preserving the ability to revert versions with a CLI line. For situations where I need to run one svn update to get a site replicated to a sandbox, I use svn:externals to package all the needed files from the various sources in SVN into a neat package i.e
:externals - core6.x
:externals - /sites/customsite_1
:externals - /sites/all/modules
With such an assembly of cheap copies (no physical duplication of files), I can svn co from this location to a new server/sandbox and immediately have the exact files on a given client's live server...
I have opened more discussion points than I wanted to, I intend to discuss each item in detail at http://idonny.com/blog where I talk about my opinion on best-practices
Good work!
Thanks!
However, we have a number of sites that were not checked out in this way and this makes updating Drupal sort of a pain. Our SVN management system wants us to update each file individually (so the changes can be versioned), but individually updating each of Drupal core's 300+ files is a little bit tedious. [http://www.growtaller4idiotsweb.co.cc/ grow taller]
... but finally I think I got it into my brain. Need to test it... Drupal's a bitch sometimes^^
Personally, I installed Drupal in a subfolder in my web root - public_html folder. Here's the mod_rewrite code I used.
(Please feel free to add the current mod_rewrite code here and give a little explanation!)
After a long struggle, I finally got the redirect to work and I was on a error 500, you may see here http://paraorkut9.org/ that could get in the INSTALL.txt file, but not php files work. I remembered Karim changed the permissions and checked with Juan, which controls security on the server that prevents files have permissions above 755. I spoke with soholife installed to see Karim had set it up, basically, I see that all php files just 644-rw-r - r - and the folders have 755 drwxr-xr-x.
When I run this find command, it seems to take all the new files and copies them into the main drupal directory of the existing installation, not into the subdirectories
the whole CVS inside of svn is sort of double work. since it sounds like you use this on a regular basis it'd be a great idea for a post if you guys can swing it.
Those events don't come up in a drupal point-release update. This procedure is not for going from v6 to v7, but rather for security updates and the like.
Orkut Scraps
SVN is great! About the only time you can go back and fix your mistakes. I am currently working on a site with a coworker http://www.orkutnow.com/ and if they change something I already worked on, it is easy to correct and conflicting code.