I was going to update to 2.3.1, but I thought I’d see if the trunk was working as expected first, and it is.
It’s actually fairly easy to upgrade using subversion, so here’s what I did.
Updated betablog(my nonpublic mirror of my working site) to trunk
using svn sw http://svn.automattic.com/wordpress/trunk/ .
Files changed:
A wp-admin/js/edit-posts.js
A wp-includes/js/wp-lists.js
A wp-includes/images/wlw
A wp-includes/images/wlw/wp-icon.png
A wp-includes/images/wlw/wp-watermark.png
A wp-includes/images/wlw/wp-comments.png
A wp-includes/wlwmanifest.xml
No files I have edited are part of this update, so I shouldn’t have to re-edit anything. svn update should incorporate the changes into files, instead of overwriting the whole file, unless there are overlapping changes. The only local modification I’ve made to this is to add my analytics tag to footer.php, but this hasn’t been modified in the repository version.
[smithers]$ svn status -u
* 6188 wp-includes/functions.php
* 6188 wp-admin/setup-config.php
? wp-config.php
? sitemap_gen.py
? robots.txt
? wp-content/uploads
X wp-content/plugins/akismet
? wp-content/plugins/code-markup.php
M 6188 wp-content/themes/default/footer.php
? config.xml
? google5422237c5650fd97.html
* 6188 wp-settings.php
? .htaccess
Status against revision: 6294
Performing status on external item at 'wp-content/plugins/akismet'
Status against revision: 23396
I’ll add a comment to wp-admin/setup-config.php to see if the file is over written or just modified.
I don’t understand just yet how to diff my copy against the repository. In other words, I can get a list of what I’ve changed since last update, but I can’t get a line-by-line list of what they’ve changed without doing an update. However, doing an update should tell me if my changes overlap, and then I can manually incorporate them, but this probably won’t ever be an issue because the only thing I’ve changed in the core files is the tag output. The analytics stuff is at the end of the file, where it’s not likely to overlap.
Added comment to wp-admin/setup-config.php
[smithers]$ svn status -u
* 6188 wp-includes/functions.php
M * 6188 wp-admin/setup-config.php
? wp-config.php
? sitemap_gen.py
? robots.txt
? wp-content/uploads
X wp-content/plugins/akismet
? wp-content/plugins/code-markup.php
M 6188 wp-content/themes/default/footer.php
? config.xml
? google5422237c5650fd97.html
* 6188 wp-settings.php
? .htaccess
[smithers]$ svn update
U wp-includes/functions.php
U wp-settings.php
G wp-admin/setup-config.php
U means repository file changed, but I didn’t change it locally. (it had status * before update)
G means it changed both places(i.e. it had status M * before update)
Removed change from wp-admin/setup-config.php
[smithers]$ svn status -u
? wp-config.php
? sitemap_gen.py
? robots.txt
? wp-content/uploads
X wp-content/plugins/akismet
? wp-content/plugins/code-markup.php
M 6294 wp-content/themes/default/footer.php
? config.xml
? google5422237c5650fd97.html
? .htaccess
M 6294 wp-admin/setup-config.php
Status against revision: 6294
So footer.php remains modified, because it wasn’t updated, and setup-config.php remains M, because even though I removed the change I made, making it an exact copy of the repository version, it’s still different from the version in my .svn directory, which is fine, because I don’t plan on checking any changes into the repository any time in the forseeable future.
Ah, svn update doesn’t change the version number, it just updates the existing code, so totally new files don’t get added, and WP still thinks you’re running the old version, even though subversion reports the revision number correctly. svn update, then svn sw is perhaps a good idea, then, so that repository changes get incorporated locally, then new files get added. I don’t know if svn sw will overwrite, but I know one way to find out. I’ll edit wp-admin/setup-config.php in my other blog that hasn’t been updated yet, and instead of svn update, I’ll do svn sw.
That results in a C status for the changed file, so that means I’ll have to manually incorporate changes. This is most likely due to the fact my comment was at the top of the file.
[smithers]$ svn sw http://svn.automattic.com/wordpress/trunk/ .
C wp-admin/setup-config.php
U wp-admin/link-manager.php
U wp-admin/page.php
U wp-admin/export.php
U wp-admin/edit-pages.php
U wp-admin/categories.php
Updated to revision 6294.
If you get a conflict, you need to do one of three things:
Once you’ve resolved the conflict, you need to let Subversion know by running svn resolved. This removes the three temporary files and Subversion no longer considers the file to be in a state of conflict.
You have to be in the directory to use svn resolved, or you get an error.
[smithers]$ svn resolved /wp-admin/setup-config.php
svn: warning: '/wp-admin' is not a working copy
[smithers]$ cd wp-admin
[smithers]$ svn resolved setup-config.php
Resolved conflicted state of 'setup-config.php'
Some themes are in subversion, too, and since themes are more often customized, it makes sense to use subversion for them, especially the complicated K2 theme.
[smithers]$ svn status -u
M * 500 theloop.php
* 500 page.php
* 500 page-archives.php
* 500 single.php
* 500 k2.pot
* 500 header.php
* 500 attachment.php
Status against revision: 582
So my changes to theloop.php will need to be merged. Let’s try svn update.
[smithers]$ svn update
D app/display/sbm/backup.php
D app/display/sbm/header.php
D css/rollingarchives.css
A css/options.css
A css/humanmsg.css
A css/rollingarchives.css.php
A css/header.php
C theloop.php
A images/sbmmanager/buttoncircle.png
A images/sbmmanager/deletebutton.png
A images/sbmmanager/undo.png
U single.php
A js/jquery.easing.js.php
A js/jquery.humanundo.js.php
A js/jquery.humanmsg.js.php
Updated to revision 582.
So I got the dreaded C for theloop.php, but I guess I should have expected that.
Rollingarchives.css is gone, interesting, and humanundo.js functions have been added. Single.php hasn’t been changed, thankfully, nor has header, footer, or style.css.
Because of the revision marks in theloop.php, the file requires resolution of the changes before it will work again. In my case, almost the whole file has changed, so I’ll have to re-add the tag code to the new version.
Lots of changes to theloop.php. One thing k2 does that I don’t agree with is that it only shows tags on single post pages. I think it makes more sense to just stick the tags in the place of the categories at the top.
Problems:
' . surrounding everything in theloop.php.the_tags(__('Tags: ','k2_domain'), ', ', '.') replacing the k2_nice_category, works, but outputs before the time and date.Current status:
theloop.php aren’t there because I need to figure out how to put them in the page of the categories.Useful subversion commands:
svn status -u shows which files will be updated when you run svn update
* means files will be updated
M means files are files I’ve changed
X means files are unversioned, but specified as an external, so this applies to WP supplied plug-ins.
? means files aren’t being tracked in subversion. Files I’ve created, such as the sitemap generator, which isn’t part of wordpress, will have ? Status.
Tags: K2, subversion, theme, upgrade, wordpress