Home/ Questions/Q 1115497
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T03:09:51+00:00

I’m using svn for the first time, to maintain a custom version of WordPress.

  • 0

I’m using svn for the first time, to maintain a custom version of WordPress. I’m using the subclipse plugin in eclipse. The time has come to merge the changes in the latest release of WordPress with my customised code base.
I have tried creating a branch and adding the new WordPress release there, then performing a merge. No changes were made however.
Could someone walk me through the setup of project like this? I fear I am missing something basic.
Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Converting wordpress project to vendor branch procedure

    If you are using svn for the first time I suppose you have not started with a clean wordpress copy, branched from there and edited the branched version, have you? 😉

    If that is so you might have a problem at your hands.

    Background

    Unlike “regular diffs” SVN merge does not compare right-side code/folders with left-side code/folders.
    While svn merge might fall back to a diff-like mechanism if it does not find a history, I would not recommend relying on that as it can be quite prone to unneccessary conflicts.

    SVN Merge is used to reproduce changes that have been recorded in the SVN history. It is like telling a painter “Hey you know how this picture looked before you added that tree on the hill? That Tree was great! Look here i’ve copied the same base picture but now it’s with a sunset. Can you paint the same tree again but on this picture with the sunset?”
    The painter might be able to reproduce the tree because he knows how he had done it. He might even have a draft somewhere.

    The picture, that is wordpress. The painter, its svn with you commanding it. The tree thats your modifications. The picture now sunset-themed is the newer wordpress version.

    What most likely you did is copy wordpress vanilla into your svn, modify it, work with it.

    To stick with the picture example, the history would contain commands like “copy whole picture, add tree, add leaves”.

    Now you bring a new version of wordpress, a new picture so to say and put it besides your older modified version. The Problem is, you human and smart know its quite much the same picture and even though the newer verison is different you just have to copy the tree, SVN does not have that knowledge. For SVN your wordpress 1.7 folder (modified) is completly distinct from wordpress 1.8. They share no history because nothing in SVNs log indicate it. SVN is a bureaucratic snob isn’t it? 😉

    Now what people do to allow svn to maintain that historic connection between wordpress 1.7, your modified 1.7 and the new 1.8 is they use branching right at the beginning of their works.

    So you would start off with a clean 1.7 wordpress in a “vanilla-wordpress” folder, store it in svn and branch it to, say, “my-modified-wp”. There you hack away until you feel like updating wordpress from upstream. People then download the latest wordpress copy overwrite their vanilla wordpress and merge the resulting changeset.

    In the picture example commands would be these:

    "Buy original picture
copy original picture as my picture
draw tree on my picture
draw sunset on original picture (someone else did that for you, aka update)
*reproduce* sunset on my picture too"

    You can cleanly reproduce the sunset because you know how the picture looked before the sunset was applied.

    Your problem though is that you did not start that way off but edited on your downloaded wordpress right away. So your newer copy of wordpress can not be easily associated with your modified version.

    One way to establish history relations

    download the **exact** wordpress version you started your project with
Put it into /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.7.1" to tag the import.
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/branches/my-new-modified-wordpress" or whatever your project/WP-edition is called.

    Now comes the trick part
    Scroll back the svn log of your “old-modified-wordpress”. The one that you did not branch. You have to find the first revision AFTER your initial import of the old wordpress. Once you found that revision you take its number and use it in the second of these two commands:

    change into a local checkout of "/branches/my-new-modified-wordpress"
issue "svn merge -r **4**:HEAD http://svnserver.tld/repositorypath/my-**old**-modified-wordpress". If 4 was the first revision during which you made own modifications.

    You are telling svn the following: “Take all changes in my old branch between revision 4 and NOW and reproduce them on my new branch.”

    If all works out you should have two identical branches. the old-modified and the new-modified with the slight difference that the new-modified has a solid history with your “/vendor/wordpress/current” branch.

    This ancestry allows you to contunously do the following:

    Download the wordpress version you wish to upgrade too and **overwrite** /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.9.3" to tag the new version.
change into local checkout /branches/my-new-modified-wordpress
issue "svn merge http://svnserver.tld/repositorypath/vendor/wordpress/current"
profit

    This procedure I describe with less storystelling at the link allready. But before it can work you have to establish the ancestry relation between the branches.

    Subversion svn:externals file override?

    I know it has been alot to read :). If you plan do soem drawing, think of “change commands” not states and you’ll be fine.

    C

    • 0