[wp-hackers] Plugin Upgrade Failing when using Subversion
harish.mlists at gmail.com
Fri Jan 16 00:33:34 GMT 2009
Mike Schinkel wrote:
> Hi All:
> I've just run into a problem with plugin upgrades failing when using Subversion for version control. Subversion stores a collection of readme files and when the upgrade process tries to delete them it fails to and then fails the upgrade process. Am I the first person on this list to experience this? It fails in a very ungraceful way, i.e. basically it just says "Sorry, sux to be you." ;-)
> Potential solutions:
> 1.) Bypass deleting any .svn directory(s) and in that case don't require the plugin directory to be deleted in order to continue the upgrade process.
> 2.) Remove the read-only attribute and delete the files.
> 3.) Something else?
> I think #1 is most preferable because it doesn't loose the Subversion info and the next check-in will check-in the new plugin info. Maybe this could be a configuration option, i.e. to do #1 by default or #2 if configured to do so instead?
> I need this fixed ASAP so I can do the work to fix it but I've yet to contribute any patches so I don't know the process.
(I apologise for joining this discussion late. I am coming in with a fix
from a different angle.)
I've been running my journal on WordPress from SVN for a long time and
have recently (few months?) begun using the click-to-upgrade plugin
functionality. I have not noticed any problems.
But I do have the following SVN properties set:
1. Ignore all file/folders under wp-content that are not 'plugins' or
Properties on '.':
svn:ignore : wp-cache-config.php
2. Ignore all file/folders under wp-content/plugins that are not part of
the default checkout (akismet, hello.php). e.g.,
Properties on '.':
svn:ignore : rssbasefix.php
svn:externals : akismet http://plugins.svn.wordpress.org/akismet/trunk/
Perhaps this will work for you.
More information about the wp-hackers