Em uma das minhas instalações do WordPress, usei o SVN para fazer a instalação inicial. Eu pensei que isso ajudaria upgrades ... e fez por algum tempo. Eu tentei com a última versão 3.0.1, e este método não funcionou. (Eu executo um svn update, executo o script upgrade.php e o upgrade.php retorna um erro.)
Então agora eu quero converter meu SVN instalado Wordpress para um regular. Qual é a melhor maneira de fazer isso?
Ou eu preciso instalar o 3.0.1 e depois importar meus dados?
Simplesmente pare de executar comandos svn e/ou apague todas as pastas com o nome ".svn" na sua pasta WordPress e em todas as pastas-filhas, o que remove os metadados do Subversion. Não há diferença entre o release do WordPress 3.0.1 obtido usando o Subversion ou como um tarball da página de downloads WP, exceto pelas pastas .svn no primeiro. O WordPress não sabe que foi instalado via Subversion.
Eu poderia recomendar uma outra pergunta explicando o que deu errado durante a sua atualização do svn para a versão 3.0.1, para que possamos ajudá-lo a corrigir esse problema. Eu tenho atualizado via Subversion para muitos lançamentos para grande sucesso.
se você quiser apenas remover todas as suas pastas .svn ...
find . -name .svn -print0 | xargs -0 rm -rf
Adam está correto, embora se livrar do SVN fará com que você perca outra vantagem: verificações de segurança fáceis. Se você souber quais arquivos pertencem ao WordPress e quais são adicionados após o fato pelos seus uploads, etc., executar um svn stat
a partir da raiz da sua instalação WP mostrará quais arquivos foram modificados. Usando essas informações, você pode potencialmente detectar arquivos principais WP que foram modificados por script kiddies, etc., caso haja necessidade. (Eu realmente detectei um par de arrombamentos exatamente dessa maneira).
Então eu concordo com Adam: qual erro você encontrou ao tentar fazer um upgrade no SVN? Talvez possamos ajudá-lo com essa resposta.
Por que não apenas svn export
seu diretório de trabalho e fazer upload de como o seu WordPress instala? Você perderá essa capacidade de acompanhar as alterações nessa cópia, mas a maior parte do tempo em um servidor de produção está correto. Toda vez que você implantar, você pode apenas svn export
novamente e usar algo como o recurso "Sincronizar" em Transmitir para diferenciar sua cópia local da que está na caixa dinâmica.
Francamente, acho que faria mais sentido apenas rastrear seus arquivos de tema (se você estiver criando um tema personalizado) e deixar os diretórios de upload e outros arquivos de distribuição do WordPress sozinhos. Se você precisar de backups daqueles que você poderia usar rsync e Subversion ou Mercurial juntos para conseguir isso, e apenas acompanhar os arquivos que você está desenvolvendo para facilitar a implantação.