Comments on: Subverting WordPress

By: Keeping things in sync with Wordpress releases via SVN using vendor branches « Tales from the Script

Tue, 20 Jan 2009 13:46:43 +0000

[...] an option (except for plugins, of course). I’m certainly not the first to face this problem; Eric Meyer has (had?) similar [...]

By: regis

regis — Tue, 09 Dec 2008 20:37:33 +0000

This worked like butter for me – in the working dir run:
svn merge curversionurl newversionurl

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

By: Simon

Simon — Sat, 25 Oct 2008 13:38:51 +0000

I support the idea for a hook that will allow easy disabling of WP”s rewrite rules. I am going to send in my patches to trac.wordpress.org too. May be they can find possibility to make it part of the core code.

By: Michael Ridley

Michael Ridley — Thu, 18 Sep 2008 16:35:54 +0000

Eric-

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

By: Scott

Scott — Wed, 10 Sep 2008 22:09:54 +0000

Andrew Nesbitt said it first so: DITO on Git/Github.

By: Ben Lowery

Ben Lowery — Thu, 04 Sep 2008 19:32:10 +0000

I do what you’re trying to do by using git and git-svn. git-svn mirrors the wordpress svn repo into my git repository and I have a branch that is effectively wordpress’ trunk + my changes. When wordpress updates, I pull the changes into git and merge them into my branch if I like them.

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.

By: Eric Meyer

Eric Meyer — Thu, 04 Sep 2008 14:50:59 +0000

Skipchris: interesting idea. I was unaware of ignore, and it would be at least similar to what I was already doing. What I really want, though, is a way to get changes to the files from the base repository while merging in my alterations. Maybe what I want isn't possible, but I live in hope...

By: Eric Meyer

Eric Meyer — Thu, 04 Sep 2008 14:48:01 +0000

Steven: you might be right. I'm not sure, though, because I don't understand exactly what you mean. I'm a newb, remember? Everything I know about subversion I learned from reading "Installing/Updating WordPress with Subversion".

By: Eric Meyer

Eric Meyer — Thu, 04 Sep 2008 14:46:01 +0000

Noel: I might want to, yes; but can't, unless there's a hook that will comment out lines 39-144 (as of 2.6.1) of classes.php. Furthermore, I think merging that change into the WP core would be a Very Bad Idea. 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.

By: Adrian Simmons

Adrian Simmons — Thu, 04 Sep 2008 10:17:11 +0000

As Peter J says, you need a vendor branch and your modified ‘local branch’, and to merge changes between them when updating.

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!

By: Andrew Nesbitt

Andrew Nesbitt — Thu, 04 Sep 2008 09:51:30 +0000

Here are two suggestions from a ruby on rails developer perspective: 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.

By: Skipchris

Skipchris — Thu, 04 Sep 2008 09:05:59 +0000

I might be being a bit newb-ish here, but would svn:ignore solve the problem?

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?

By: David

David — Thu, 04 Sep 2008 08:03:02 +0000

Obviously you need SVN with a half gainer. That’s the trick.

By: Steven Ametjan

Steven Ametjan — Thu, 04 Sep 2008 05:45:38 +0000

Maybe I’m under-thinking this, but could you not just merge the tag into your working copy?

By: Jilles van Gurp

Jilles van Gurp — Thu, 04 Sep 2008 05:21:07 +0000

I’ve used the vendor branch pattern for a while and it’s a bit messy. I ended up with a non working setup several times only to find out that the merge somehow resulted in a setup that was quite different from what is actually in the wordpress svn. I’ve given up on the notion of maintaining my handful of modifications for now.

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.