http://techblog.touc[...]isting-code/

http://techblog.touc[...]-core-files/

I’d like to know how you maintain local changes on each site with only an ’svn up’ to get your modified wordpress files.

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.

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 =)

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.

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.

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.

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.

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.

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.