Incorrectly flagged as "using SVN"

It does this for safety reasons. And it actually crawls all the way back up to the root looking for any form of version control directories.

The basic thinking here is that maybe WordPress is only a part of your site, and you have the whole site, or even multiple sites, in revision control. So if your site lives at /home/www/public_html, and WordPress is installed at /home/www/public_html/mysite.com/wp, then we’d want to handle that correctly. So any form of revision control, all the way back up to the root, will stop the auto-updater.

You can still one-click manually update though.

If you want to force the auto-update on for this case, then there’s a filter just for that. Return false to “automatic_updates_is_vcs_checkout” and it’ll ignore the revision directories.

add_filter( 'automatic_updates_is_vcs_checkout', '__return_false' );

As @nacin also notes in this post, you can be super-specific about what directories can update, if you want to:

The definitive guide to disabling auto updates in WordPress 3.7

Edit: Fixed true/false error.

Starting with Subversion 1.7 (and for as long as I’ve worked with Git), there is only a .svn (or `.git) directory at the top of the repository.

The most common example would simply be using WP as an SVN external or Git submodule at the very top of the repo — we would still need to look up a level in that case. But at that point, you start to realize that you could store more than your public_html root in version control. Maybe next to public_html, you have an includes or bin directory? If all of that sits in version control, we have to go two levels up.

Say /home/ozh/sites/public_html/wordpress/ is your WordPress install. You could have /home/ozh/sites be a version control checkout, and /home/ozh/sites/public_html/wordpress be an external.

It errs on the side of caution in order to find any possible trace of version control. We especially wanted to avoid touching any existing server or code deployment setups. That’s why it looks all the way up the stack.

To be honest, I didn’t consider ~/.svn. As far as I knew, that was always ~/.subversion, with .svn reserved for actual checkouts. I’ll do some research. That’s something we may be able to detect, I guess.

Actually, in looking at the code, I believe @nacin may have meant to say to return false through that filter to have it ignore the version control directories.

Try it either way. One of them will enable it to ignore the .svn directory. ??

I would consider detecting ~/.svn an unfortunate side effect, and something we should fix, but I can’t seem to find any indication that ~/.subversion would instead be called ~/.svn. I also checked a few different shared hosts as well.

Could you check to see if that is, for some reason, actually a working copy somehow? Perhaps a .svn got moved there at one point? Does ~/.subversion also exist? What are the contents of ~/.svn? Does svn info ~ return anything?

Ah, I think I get it. I have indeed both .subversion and .svn, and it seems .subversion has the client informations. That .svn directory looks like an old leftover from something, as shown with svn info. I’m deleting it.

Thanks! ??