so going from 2.6.3 to 2.6.5:

svn merge http://svn.automattic.com/wordpress/tags/2.6.3 http://svn.automattic.com/wordpress/tags/2.6.5

I wrote a post on this the other day for our company blog, but what I do is keep my Subversion copy of WordPress empty except for the things I’ve changed – plugins, new themes, etc. I apply the new WordPress release directly to the “live” copy, and I merge in any changes to the files in the working copy as new releases come out. Since I am only modifying a tiny subset of the WordPress code, there’s no benefit to me to having the entire WordPress code base in my Subversion working copy.

This approach works for me because I am mainly editing custom themes or plugins which are in no way affected by WordPress updates. I do sometimes hack on the main code tree, but it’s only one or two files so it doesn’t inconvenience me to update that if the main line code changes.

By following this strategy I try to keep my custom client-specific WordPress code independent of the version of WordPress that’s actually installed on the live web site. It works pretty well.

Hope that was helpful!

-m

The repo is at http://www.github.com/blowery/wordpress if you want to take a peek (http://github.com/blowery/wordpress/tree/ben%2Ftrunk is my branch of wordpress). I also use a git submodule to track the theme I use, but that’s another story. Another nice thing about doing it this way: my plugins, uploaded content and other ephemera for my particular install are all captured in git. With plain svn, this is a bit harder.

As others have said, you can do this with svn vendor branches too. I just did it with git because I happen to like it better, and I find it easier to maintain my branch with it.

Ditto edit-form-advanced.php, in which I rearranged some of the markup to be more to my liking. I don’t think a plugin will be able do that for me, and having those changes in core isn’t a great idea either.

I have asked in the past for a hook that will allow easy disabling of WP’s rewrite rules—I have my own, and don’t want WP fighting me over them—but so far as I know it still doesn’t exist. If it’s ever added, I’ll gladly stop modifying classes.php and write a plugin to do what I need. Until then, though, I’m stuck with this situation, which is a serious drag on my enthusiasm for upgrades.

You might also want to check out SVK, it works with SVN but has much better merge – the same principle applies though, use a vendor branch!

1. Github is the new hottness in hosted version control, there are a number of daily updated mirrors of the wordpress subversion repo there, you could fork wordpress on there, add your changes to the files you need and still keep up with the master branch of wordpress.

2. Using a tool like capistrano, you could automate the checkout and deployment of wordpress from subversion and setup a simple after deploy task that symlinks in your custom files and assets into the wordpress folder after it has been checked out.


svn propedit svn:ignore wp-blog-header.php,
svn propedit svn:ignore wp-includes/classes.php,
svn propedit svn:ignore wp-admin/edit-form-advanced.php


Maybe?

A possible way out would be to use a more capable distributed versioning system like mercurial or GIT that is able to pull changes from upstream into a local branch and has more robust merging.