私のWordPressインストールの1つでは、SVNを使って初期インストールを行いました。私はこれがアップグレードに役立つと思いました...そしてそれはしばらくの間しました。私は最新のリリース3.0.1でそれを試しました、そしてこの方法はうまくいきませんでした。 (私はsvn updateを実行し、upgrade.phpスクリプトを実行するとupgrade.phpがエラーを返します。)
だから今私は私のSVNをインストールしたWordpressを通常のものに変換したい。これについて最善の方法は何ですか?
または、3.0.1をインストールしてからデータをインポートする必要がありますか?
Svnコマンドの実行をやめるか、WordPressフォルダ内の ".svn"という名前のフォルダとそのすべての子フォルダを削除するだけで、Subversionメタデータが削除されます。 Subversionを使用して入手したWordPress 3.0.1リリースと、WPダウンロードページからtarballとして入手したWordPress 3.0.1リリースの間に違いはありません。前の.svnフォルダー用に保存してください。 WordPressはSubversion経由でインストールされたことを知りません。
私たちはあなたがその問題を解決するのを助けることができるように3.0.1へのあなたのsvn更新の間に何がうまくいかなかったかを説明する別の質問をすることを勧めます。私はSubversionを介して多くのリリースを大成功にアップグレードしてきました。
あなただけのすべてのあなたの.svnフォルダを削除したい場合は...
find . -name .svn -print0 | xargs -0 rm -rf
Adamは正しいですが、SVNを取り除くと別の利点を失うことになります:簡単なセキュリティチェック。どのファイルがWordPressに属し、アップロード後などに追加されたファイルであるかがわかっている場合、WPインストールのルートからsvn stat
を実行すると、どのファイルが変更されたかがわかります。この情報を使用すると、必要に応じて、スクリプトキディなどによって変更されたコアWPファイルを潜在的に検出できます。 (私は実際にはまさにこの方法でいくつかの侵入を検出しました)。
それで、私はAdamに同意します:SVNアップグレードを試みるとき、あなたはどんなエラーに遭遇しましたか?おそらく私たちはその答えであなたを助けることができます。
作業ディレクトリをsvn export
してWordPressのインストール時にアップロードするのはどうしてですか?あなたはそのコピーの変更を追跡するその能力を失うでしょうが、大抵の場合本番サーバーでは大丈夫です。デプロイするたびに、もう一度svn export
して、Transmitの "Synchronize"機能のようなものを使って、ローカルコピーをライブボックス上のコピーと比較することができます。
率直に言って、私はあなたのテーマファイル(あなたがカスタムテーマを作成しているなら)だけを追跡し、アップロードディレクトリと他のWordPress配布ファイルだけを残すことがより理にかなっていると思う。それらのバックアップが必要な場合は、rsyncとSubversionまたはMercurialを併用してそれを実現し、開発を容易にするために開発中のファイルのみを追跡することができます。