bragur,
I’ve been using Subversion for a few years, but I don’t think there is a good way to have ones’ WordPress site stored in Subversion and be able to update WordPress. Subversion has .svn folders under each folder, so if you do just replace out everything but the wp-content folder, you will end up losing those .svn subfolders and it will no longer be a Subversion working directory.
Another approach would be to checkout WordPress from a tagged version and just update the tag as needed. Unfortunately, the directory layout doesn’t really work.
In a Ruby on Rails project, Rails and the plugins would be stored under a vendor/ folder and use svn:externals. The way WordPress is structured, we put our custom themes under it, and we can’t check them in to the main repository, or even use an svn:external. Perhaps this could be worked around via a symlink for wp-content, but images are referenced from the wp-content/ url too, so it’s just a mess.
The one approach that could work with Subversion and WordPress is using vendor drops. These are described in the “Pragmatic Version Control using Subversion“. It’s a process that allows you to maintain your own copy of a vendor’s code and update it via a Perl script, while maintaining your own changes (which could be your theme, or tweaks to the core). It’s a bit tedious… but let me experiment with it. Since WordPress has tags for each release, maybe I can find a way to simplify the process.
Alternatively, I was thinking of going to something like Mercurial. It only has one .hg folder in the root, so one could just copy the files in and commit. It also has something called Mercurial Queues, which would allow you to maintain changes to the core and “rebase” with a new version. It doesn’t integrate with subversion however, and I’m just getting started learning it.
Could also look into Git, which can checkout from SVN, especially handy if you want to work with edge WordPress. It’s somewhat more complicated to use than SVN or Mercurial, so I haven’t looked into it yet.
