I’ve got 4 installs of WordPress running various sites of mine, and I plan to migrate a few other sites to a WP backend at some point as well. This becomes a bit of a maintenence nightmare when I need to do upgrades or apply patches. Because of this, I’m considering doing an SVN checkout of WP on each site to make them easier to maintain.
The only issue is that I’ve got a few places in the WP core that I’ve customized for some of the sites – I’d potentially have to re-apply these patches and resolve any conflicts on each update. It wouldn’t be that big a deal though:
- alexking.org – I’d need to apply my patch to not require unique post slugs and I’d need to redo some of my site structure sincce I’ve got stuff hanging around from the b2 days.
- kingdesign.net – the unique post slugs issue and I hacked the search function to return “pages” as well as posts in the search results. If this isn’t standard in 2.0 (haven’t checked) I’d need to apply those changes.
- feedlounge.com – the new roles system should allow me to drop my hack to allow Scott and I to view and edit each other’s posts. Then it would just be a matter of the unique post slugs and search results.
I think that re-applying these patches to the latest from SVN would be easier in the long run than updating each install individually.
I guess I really want a process like this:
- Update WP to latest from WP’s SVN repository
- Check my mods and fix any issues
- Test and commit to my respository
- Update on production sites
I don’t know how to do this with SVN, though perhaps there is a way. Maybe the right way to do this is to get latest, make my changes, then create a patch. Then update the production sites to the latest from WP’s SVN and apply my patch.
When you work by yourself most of the time, the simplest parts of source control (branch, merge) are all you generally need. One thing I miss about working in a BigCo is absorbing this kind of knowledge by necessity without having to track it down. 🙂
Are you trying to do everything with SVN or looking for just downloading via SVN and then doing the remaining 3 steps yourself?
If you are looking for just updating via SVN, I have written how to.
I know how to get updates from SVN, I don’t know the best way to then apply my changes to all of the installations.
The cleanest way to do this purely with Subversion is keeping three repositories (joy):
* Official
* a pristine copy
* with modifications
After updating official, generate a patch against pristine. Apply the patch to patch to both pristine and modified. Comit, then have sites pull from the modified.
This is exactly the situation that’s driven me to use distributed versioning systems (Arch, Darcs, Monotone). Personally, I use Darcs with Tailor to avoid ugliness like the above.
SVN will replace any files that have been changed that it still keeps track of — while it’s useful to hack the core files, it’s a bad habit to get into once SVN is thrown into the mix.
An option is to move your custom code into modular files that can be include’d as required (or into a plugin, for that matter). Keeps the custom code clear of the SVN repo. Using an ‘include’ or plugin would drastically reduce update hassles.
Option number two is to create your own SVN server. It should be possible (but not necessarily easy) to have a central SVN copy, that you can adjust then draw down as required to each site..
There are options – however I suspect separating code out into custom modules for each site would be the most SVN friendly.
I’m using SVK to maintain my modified WP. SVK makes it quite easy to manage your own private branches of SVN repositories.
You can setup a local mirror with:
svk mirror http://svn.automatti[...]dpress/trunk //wordpress/trunk
svk sync //wordpress/trunk # takes some time
Then create a local branch with:
svk cp //wordpress/trunk //wordpres/local
# Checkout local branch
svk co //wordpress/local
Now you can work with your local branch, usage is quite similar to svn. To resync with the upstream repository just do:
svk up -sm
Would like to know too!
Subversion supports a feature known as “externals”, which lets you pulll changes from a remote repository automatically. I don’t know what would happen if you tried to commit to a file from the external repository, though.
Another possibility is SVK, which adds decentralized features on top of Subversion. You could use this to sync the WordPress repository, then create a local branch for the nonunique post slugs patch. From there you could create a branch for each site.
You can (on Windows with TortoiseSVN at any rate) right click on a file and press exclude to stop it from being upgraded.
That is the fastest/easiest way, but not practical. You can create a diff package, save it, then after every svn update apply the diff package. that is prolly the best way for you.
The way I handle these upgrades is by using diff to create patches of my local changes and then I try applying those patches to the new checkout. That’s easiest if you used an SCM to checkout the previous version but even if you didn’t you can put a pristine copy somewhere that you can diff each installation against. Then use diff to create a patch file that you can apply using the patch command. Then try and apply those patches to the newest checked out SVN version. There will likely be conflicts that need manual resolution, however, I find that often the changes apply just fine to modules that haven’t changed significantly.
This is how I go about upgrading my Durpal installation. As an aside I’ve written a post on how I manage my local PHP projects by doubling up source control using both CVS and SVN.
http://jroller.com/p[...]rol_with_cvs
Alex,
I used to do this all the time with b2 and CVS all those years ago. I used CVS’s vendor branch capability. It was always easy, and I have about a dozen core files hacked.
SVN will have something similar. All those above who forecast disasters are wrong. SVN is a superior version of CVS by design and CVS could handle it quite easily. See the SVN book for details
http://svnbook.red-b[...]endorbr.html
svk sounds good but it isn’t solving your problem. You don’t need a mirror of WP’s SVN repo, you need the old vendor branch concept.
Alex,
I don’t know enough about SVN to help directly, but I can offer one way to simplify the problem for you:
kingdesign.net could search pages with a plugin rather than hacking the core, which should improve life when updates roll around. I’ve used this plugin with some success. I’ve only tested it lightly with WP2.0.
Thanks for all the comments…
Nikolas – yeah, I don’t like that much either.
brendan – not all changes can be so cleanly made. I do have my own SVN server, which is what I’m discussing using here.
Juergen – sounds interesting, see Mike’s comment below.
Daniel – I didn’t know about externals, sounds very handy.
Todd – that is what I’m leaning towards, but I’m interested in the vendor branch concept too.
Mike – why am I not surprised you have an answer for this? 🙂 That sounds exactly right, I guess I need to do some reading.
Barry – the given issues are just the effects of the problem, I want to solve the cause in a way that works going forward.
I read the chapter on vendor branches. It’s what I outlined before, with the substantial bonus of a perl script to automate a lot of the grunt work. I think the CVS process is might be usable.
I’ll note (for the heck of it) that SVN is not better than CVS in all areas. The most common example is renames. SVN deletes the old name and adds the new, losing history between the two. You can of course use a heuristic to surmise the A was deleted and B was added in the same revision and, gee, they look very similar.
Mike’s comment is wrong: The little svk example gives you what CVS and svn call a ‘vendor branch’. The difference is that it makes merging a lot easier.
The ‘svk up -sm’ cmd is a short cut for updating your local mirror of the WP repository (ie. the vendor branch) and merging the changes it into your branch.
Jeurgen,
Thanks for that clarification, I had completely mis-interpreted the abilities of svk. Though the website only mentions mirroring in it’s opening section.
Should be fairly easy to do. Bugzilla has long supported upgrading via CVS, and I don’t see any problems with doing the same via Subversion.
The whole point is that you pull in the latest updates from the repository and they are merged with your local changes. You should only have to intervene is there is a conflict that Subversion can’t resolve automatically.
See the Subversion book (svn update command) and also Bugzilla:
http://www.bugzilla.[...]ownload/#cvs
For some time now Bugzilla has actually shipped with CVS information in the distribution archive so that people don’t even need to do the initial checkout. I think this would be a good idea for WordPress too.
Unless I’m misunderstanding, just pulling from SVN (it would be nice if there was a ‘stable’ branch or tag to pull from) doesn’t allow me to make changes, commit them to my own repository, and then distribute those updates.
My suggestion (and the way Bugzilla updates via CVS work) is that you do updates like this:
1. Initial checkout (instead of a normal install).
2. Apply your changes.
3. Do future updates using the “svn update” command. This should merge updates from the repository into your local working copy, preserving your local changes and only requiring intervention in the event of an unresolvable conflict (which you’ll have to resolve by hand).
In my experience with Bugzilla and a customized install (http://bugs.wincent.com/)I’ve never had an unresolveable conflict and upgrades have been quick and painless.
Bugzilla does provide a “stable” tag. I don’t know if WordPress does the same. You could specify a specific revision number using the “-r” command line switch (ie. rather than updating to HEAD).
This is a very easy way to keep multiple installs up-to-date even if they have customizations. It’s not really intended for the use that you mention in your last comment (“make changes, commit them to my own repository, and then distribute those updates”). If you wanted to make local changes and redistribute them you could do an “svn diff” and redistribute the diff, but i don’t think you can check out from the authoritative WordPress repository and then commit changes to some other, local repository.
Right, that is one of the possible solutions I listed.
I think your suggestion works great for managing a single install, but doesn’t address the problem I’m talking about here.
Yeah, but I think it helps. Instead of painstakingly merging changes on four different installs, you just type “svn update” four times.
Sure, but isn’t it easier to pull WP into my own SVN, apply my changes, then type svn up on the 4 sites? Otherwise I have to svn up each site and merge my changes. That’s what this whole post is about. 🙂
Alex – the only way you are going to get around not having to ‘svn up’ on four different sites, is if they are on the same server.
Then you can just symlink the directories… but that makes things hairy with uploads.
Either that, or not keep your modified WP in subversion… and use FTP (*gah*) to get your latest version on there =)
My $.02 – there is no simple magic one-step bullet, w/o writing a really complicated shell script.
We’re actually doing this on the NinerNiner.com network of blogs – each have a modified version of WP that we use.
Whenever WordPress releases a new version, we update our private svn repo, make sure our changes are still in there… then svn up on each of the blogs.
Of course, with 24 blogs, we have a shell script that does that =)
[…] This post is inspired by Alex King’s WordPress updates via Subversion. […]
You can still retain your modified WP in SVN and use Apache Ant build scripts to deploy the code to your servers. I’m using the Eclipse IDE with subclipse and svnant installed to do just that.
http://acm.cs.ucla.e[...]introduction
My Ant build scripts simply check out code from different repositories into a temp build directory and FTP that to the appropriate server. It just drops my customized repository code (that only contains my core changes) on top of the trunk/branch.
The hard part is then making sure your customized repository contains all the core files you modified and making sure those core files are updated with the latest code, which was detailed before using diff patchs. That way, you can keep different repositories that hold your plugins and themes unique to each install.
@Shanti – “Whenever WordPress releases a new version, we update our private svn repo, make sure our changes are still in there… then svn up on each of the blogs.”
I’d like to know how you maintain local changes on each site with only an ‘svn up’ to get your modified wordpress files.
Just wanted to update this post with the following links, which describe how to use vendor branches to achieve this goal:
http://techblog.touc[...]isting-code/
http://techblog.touc[...]-core-files/