How to convert a WordPress install under SVN to one that is not?

Question

On one of my WordPress installs, I used SVN to do the initial install. I thought that this would help upgrades...and it did for awhile. I tried it with the latest release 3.0.1, and this method did not work. (I perform an svn update, run the upgrade.php script and the upgrade.php returns an error.)

So now I want to convert my SVN installed Wordpress to a regular one. What is the best way to go about this?

Or do I need to install 3.0.1 and then import my data over?

Answer 1

Simply stop running svn commands, and/or delete all the folders named ".svn" in your WordPress folder and all child folders, which removes the Subversion metadata. There is no difference between the WordPress 3.0.1 release obtained using Subversion or as a tarball from the WP downloads page, save for the .svn folders in the former. WordPress doesn't know it was installed via Subversion.

I might recommend asking another question explaining what went wrong during your svn update to 3.0.1, so that we might help you fix that problem. I have been upgrading via Subversion for many releases to great success.

Answer 2

if you just want to remove all your .svn folders...

find . -name .svn -print0 | xargs -0 rm -rf

Answer 3

Adam is correct, although getting rid of SVN will cause you to lose another advantage: easy security checks. If you know what files belong to WordPress and which are added after the fact by your uploads, etc., running an svn stat from the root of your WP install will show you which files have been modified. Using this information, you can potentially detect core WP files that have been modified by script kiddies, etc., should the need ever arise. (I've actually detected a couple of break-ins in precisely this manner).

So I agree with Adam: what error did you encounter when attempting an SVN upgrade? Perhaps we can help you with that answer.

Answer 4

Why not just svn export your working directory and upload that as your WordPress install? You'll lose that ability to track changes in that copy, but most of the time on a production server that's ok. Every time you deploy you can just svn export again and use something like the "Synchronize" feature in Transmit to diff your local copy against the one on the live box.

Frankly, I think it would make more sense to only track your theme files (if you're creating a custom theme) and leave the upload directories and other WordPress distribution files alone. If you need backups of those you could use rsync and Subversion or Mercurial together to accomplish that, and only track the files you're developing in to make deployment easier.