9

1 つのリポジトリに複数の Web サイト プロジェクトがあり、それぞれに WordPress のコピーがあります。WordPress の更新とは、すべてのプロジェクト フォルダーを更新し、冗長コピーを保持することを意味します。これは、フォルダー全体を同期する rsync スクリプトに役立ちます。また、完全に機能するサイトのローカル コピーも提供されます。

これを改善する方法はいくつかありますので、フィードバックをお願いします。私は Windows を使用しており、最近 Subversion に移行しました。

  1. 各 Web サイト フォルダー内の WordPress ビットへのシンボリック リンクを作成します。これは Subversion と Apache で持ちこたえますか。欠点はありますか？
  2. 単一の WordPress フォルダーを用意し、それを他の Web サイト トランクに分岐します。ブランチは安価で、単一のコピーが維持されていると読みましたが、ブランチをトランク全体で行う必要があるかどうかはわかりません。個人的には、これが最良のアプローチだと思います。これを避ける理由はありますか？
  3. 最後に、現在の構造を維持し、スクリプトを使用してすべての Web サイト フォルダーにコピーを作成することができました。

最善のアプローチは何ですか?代替ソリューションはありますか?

4

8 に答える 8

18

1つのオプションは、WordPressのビットを別のリポジトリに分離し（実際にはプロジェクトの一部ではないため、それらを構築するために使用するものにすぎないため）、svn:externalsを使用してプロジェクトの正しい場所にフェッチすることです. .

SVN ブックの外部定義

于 2009-03-21T17:45:13.730 に答える
7

すべてのサイトを 1 つのリポジトリでまとめてホストしている場合は、svn:externals を使用して、同じリポジトリのさまざまな部分をさまざまな方法でまとめることができます。

たとえば、次のようなリポジトリを使用します

レポ/サイト1
レポ/サイト2
レポ/コモンピース

「commonPieces url-to-repo/commonPieces」と言う site1 および site2 ディレクトリに「svn:externals」プロパティを導入できます。

ここでは明らかに再帰ループを避けたいと思うでしょう。しかし、これにはすべてが同じリポジトリにあり、履歴を共有できるという利点があります。「svn copy」を使用して、より一般的になっているものを site1 または site2 から commonPieces にプルできます。

私が取り組んでいる現在のソリューションと比較してください。個別のプロジェクトリポジトリから単一の個別の「coreLibraries」リポジトリに移行すると、開発履歴が失われます。私たちは通常、1 つのプロジェクトの機能を開発してから再利用することを決定するため、この履歴の損失は頻繁に発生します...

編集: site1 の「svn update」は、この「svn:externals」プロパティを使用して commonPieces を自動的に更新しますが、site1 の「svn commit」は、site1/commonPieces で変更されたものを表示しないことを覚えておく価値があります。1 つは site1 から、もう 1 つは site1/commonPieces から、2 つの別々のコミットを行う必要があります。

于 2009-03-21T17:57:09.490 に答える
3

WordPress リポジトリを指すsvn:external定義を追加するか、使用するプラグインとカスタマイズを使用して独自の「カスタマイズされた WordPress リポジトリ」を作成することができます。

于 2009-03-21T17:45:57.007 に答える
2

さまざまなプロジェクトで同じクラス ライブラリを再利用することがよくあります。私の場合は、プロジェクトごとに個別のフリーズ コピーを使用することを好みます。唯一の理由は、ライブラリの 1 つが古くなった場合に備えて、しばらく取り組んでいないプロジェクトを壊したくないということです。ただし、各プロジェクトが一種のメイン プロジェクトの一部である場合、常に取り組んでいるプロジェクトは異なります。

于 2009-03-21T17:47:16.660 に答える
1

Subversion の使い方が間違っているだけかもしれませんが、フォルダー構造は次のようになります。

トランク - コア - メッセージング - 超強力なアプリケーション #1 - 超強力なアプリケーション #2 - 超強力なアプリケーション #3

したがって、すべてのアプリは同じ Core および Messaging コンポーネントを共有しています。これの唯一の欠点は、人々が分岐したときにすべてのアプリケーションを取得することですが、それは何よりも厄介なことです.

于 2009-03-21T17:46:08.597 に答える
1

これを行うためのより良い方法は、wordpress をリポジトリの別のブランチにプルすることです。次に、Wordpress へのパスを格納する構成ファイルを各 Web サイトに導入します。この場所を php インクルード パスに追加できます。これが図です：

Svn repo-v
         |-Websites--v
         |           |---One
         |           |---Two
         |-Wordpress-v
                     |---branch one
                     |---branch two

これにはいくつかの利点があります。

  • テストなどを行うために、Wordpress の複数のバージョンを一度に試すことができます。これらをすべてのウェブサイト間で共有できます
  • wordpress がどこにチェックアウトされているかを心配する必要はありません。プロジェクト内にライブラリを含めるのは面倒なことがよくありますが、このタイプのセットアップを使用すると、一般的な場所に簡単に配置できます。
  • ライブラリの複数のバージョンを維持する必要はありません。更新ははるかに簡単です。
于 2009-03-21T17:49:36.280 に答える
0

従来、SVN ではすべてを分離する必要がありました。さまざまな領域からコードを取得してそれらをつなぎ合わせる手段として SVN を使用しているようです。

つまり、ビルドツールとして SVN を使用しています。次のことをお勧めします。

  • プラグインを別々に保つ
  • ベンダー ブランチを使用しない限り、wordpress 自体を SVN に保存しないでください。
  • 特定のコンポーネントを含む特定のアプリを取得する必要がある場合は、ビルド スクリプトを使用します。
于 2009-03-21T17:51:56.913 に答える
0

最善のアプローチは何ですか?代替ソリューションはありますか?

話題を逸らすつもりはありませんが、 gitをよく見てみることをお勧めします。私たちはサブモジュールを使ってこの種のことを日々行っていますが、それは簡単なことです。

参考までに-これらのタイプの問題により、約2年前にSVNから移行しました。

于 2009-03-21T18:00:25.300 に答える