それが少し話題から外れたGRINになったので、私はこの回答をブログ記事にするつもりです。上http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/第6章では、私は、EclipseでSVNのためのいくつかの説明をしたが、あなたはおそらく探しています他の何か。
私がここで作った話はあなたのコメントについてでした
「つまり、今のところ、IDE（NetBeans、PHPStorm）のVCS統合機能を使用しています。そのため、仕様や適切な処理方法に混乱することがよくあります。」そして、「コンソールに難解な行を入力するのではなく、概念とワークフローに焦点を当てたもの」
たとえば、「プログラミング言語」を最初に説明し、次にPHPを説明することで、PHPをよりよく理解できるようになることを聞いたことがあります。この場合、構成管理を最初に理解し、次にSVNソリューションを理解します。
ここに何かを入力するだけで、トピックから外れている場合や不要な場合は削除します。
------------ 8 <----------------
Eclipse PDPをインストールする場合、私はこれを書きました：[ http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ ]
＃6まで下にスクロールすると、collabnetサブクリップをEclipseにインストールする方法を簡単に説明します（基本的に、サーバーをポイントしてすべてを選択してインストールします）
どのようなバージョン管理ツールを備えたEclipseでも、バージョン管理用のコマンドは常に右マウスの[チーム]をクリックします。プロジェクトを切り替えることができるため、複数のバージョン管理ツールをサポートすることができ、ほとんどのコマンドはGUIを介したツールより使い慣れています。
プラグイン
ご存じのとおり：新しいWordPressプラグインプロジェクトの場合、WordPress.org（メールボックス内）からsvnの場所を取得し、最新のコードにはトランクを使用し、安定したリリースには「タグ」コピーを使用します。（非常に基本的なCMパターン）。これは一見したところです。
したがって、プロジェクトはTRUNKにリンクされます。あなたは単にそれにコミットすることができます。これは、作業する場所です（ただし、リリース元ではありません）（最終コードの場所としてreadme.txtで 'trunk'を指定しない限り）。
さらに、WordPress / wp-includesおよび/ wp-adminをライブラリーとしてEclipseプロジェクトに含めることができるため、関数を検索して非推奨の関数を確認できます。これらは書き込み可能ではないため、バージョン管理（！）に該当しません。これはクライアント側からのものであるため、バージョン管理プロジェクトで実際にリンクする「外部」ではありません。
安定したバージョンができたらすぐに、ものを選択して「チーム」を右クリックし、「タグ/ブランチを作成」してください。これにより、WordPress svnの場所が開き、タグディレクトリを選択して新しい番号を入力すると、新しいバージョンが公開されます。 （多分これを読んでいる人にとっては役に立つでしょう）。プロジェクトのルートを選択する必要はありませんが、他のすべてのルートは、tags / 2.3.4の下にもルートを作成することに注意してください。
スクリーンショットについては、投稿をご覧ください。
http://wp.leau.co/files/2011/02/image_thumb17.png
WordPress自体の貢献者
あなたが貢献者であれば、上記と同じように使用できますが、加えた変更から「パッチ」を作成します。「パッチ」は、CMの世界におけるコンセプトです。たとえば、SubversionはこれまたはジャズRTCを提供します。WordPressトランクにまだ適用されていないパッチがある場合は、マウスの右クリックで[パッチの適用]を使用してパッチを適用できます。
トランクに直接コミットする人もいます。
WordPress自体を「読む」
（サブバージョンコードの）トランク内の/ LATESTバージョンのチェックアウトを含むプロジェクト「WordPress」を作成し、もう一度、チーム>チェックアウトを実行します。
個人的に私はこれをしませんが、最新のコードのエクスポートを使用して（強制的に）、最新のWordPressバージョンのディレクトリを取得します（バージョン管理に該当しません）
一般に
VCSおよびSVNに関する質問の経験があるので、基本的にすべてのバージョンツールは、名前の付け方の概念に関するものです。または、より良い名前空間を持っていると言いました。CVS、Git、RTC、ClearCase、SourceSafeなどのほとんどのコマンドを、この名前空間に関する概念にマッピングできます。他のツールについてある程度の経験があるので、少し広めに：
新しい人々はしばしば、特定のコマンドや特定の機能に目をつぶっていますが、名前空間に必要なすべての要素を配置するための最良のオプションを提供することがコアです。
したがって、これは基本的にこれらのツールのコア機能であるため、「バージョン管理」という用語は間違っています。これは実際には名前空間マネージャーです。
だからあなたが持っているなら
/プロジェクトA /部門B /チームC /メンバーD /ストリームE /コンポーネントF /エレメントG /ブランチH /ブランチI /バージョンJ
各「もの」に一意の名前を作成できます。上記は、名前空間ツールの1つを使用して特定の目的に必要な名前空間の実装です。
この世界のほとんどすべての概念をこれにマッピングできるため、カスタム名前空間/分類法をサポートできる方法は、ツールの機能によって異なります。したがって...それは、何百もの異なるツールの設計者が行った概念と選択に本当に依存します。
優れたツールでは、この完全な分類法をクリックして1つのツリーで表示するか、その1つのツリーでズームインできます。
それがコアです。カスタム分類法を管理するための優れたツールを提供することで、複雑さを管理するのに役立つツール（wikipedia：http : //en.wikipedia.org/wiki/Complexityを参照）です。分類法を設定する方法を考える分類法を作成する人は、これを最初に考えて、構成管理計画と呼ばれる計画を作成する構成マネージャーです。
誰かがWordPressで自分の会社のすべてのオブジェクトを表す一連のカスタム分類法を作成するように求めていると想像してみてください。あなたは多くのデザインの選択をすることができ、誰もがいくつかの選択に基づいて別のものを作り出すでしょう。いくつかはより多くの機能を含み、いくつかはより単純で、より複雑なものはすべて異なる決定をしました。これが「これらのツール」です。したがって、バージョン管理についてのツールレベルの議論はまったく奇妙なので、理解できません。
最近のPHPでは、名前空間を作成してディレクトリで階層を作成し、オブジェクトとそのメソッド内で命名規則を適用できます。階層に配置した1つのファイルを取得する場合は、さらに一歩進んでください。その後ろに/を追加し、その後ろにバージョン番号を配置します。チームAがファイルのバージョン4で作業し、チームBがそのバージョンで作業する必要があるため、それだけでは不十分です。したがって、別の/を追加し、ブランチIDを追加します。これは、名前空間を構築する方法です。ツールによっては、好きなだけクレイジーにできます。
しかし、それは意味します。誰かが「ドキュメントZはどこですか」と尋ねてきたら、答えを出すことはできません。バージョン管理システムには「ドキュメントZ」が存在しないためです。そして、彼が「ドキュメントZバージョン5」と言っても、チーム1ブランチの「ドキュメントZバージョン5」またはチーム2ブランチの「ドキュメントZバージョン5」を意味する可能性があるため、それを引き渡すことはできません。それはすべて命名に関するものです。「ドキュメントZバージョン5」は、定義された名前空間での正しくない命名方法です。
Subversionではこれが制限されているため、理解しやすくなります。これに一致するいくつかの概念：
"バージョン"
バージョンは、特定の要素のリビジョンです。したがって、たとえばwp-config.phpバージョン5です。ClearCaseのようなツールでは、要素の個々のバージョンを確認し、個々のファイルを「コミット」することもできます（ただし、アトミックコミットや変更セットなども実行できます）。
Subversionでは、バージョンの処理がさらに制限されます。
- ローカルで一度に行う一連の変更は「コミット」されます。つまり、「変更」の完全なセットがアトミックにコミットされ、ベース全体が新しいバージョン番号を取得します。これは、WordPress subversionサイトに表示されるバージョン番号です。
- そのため、1つのファイルにローカルでそれ以上の変更を加えて、それらすべてをクリアケースのように単一の新しいバージョンとして扱うことはできません。その1つのファイルまたはその他のファイルに対してローカルで行ったすべての変更は一度に送信され、その「一意の新しい名前」が付けられます。
- リポジトリ（権限）にアクセスできない場合は、一連の変更を加えて、それらを「パッチ」に保存できます。次に、そのパッチを統合マネージャーや、リポジトリに適用するビルドマネージャーなどの誰かに送信できます。RTCなどのツールも「パッチ」をサポートしています。つまり、1人がパッチを作成し、もう1人がパッチを適用します。単語は「パッチ」を意味するので、コード開発のデフォルトのユースケースではないので、これを本当に考慮する必要があります。
- / branch N / hello.doc / version 25の代わりに、/ branch N / hello.doc / LATESTや/ HEADなどのラベルもあります。一部のバージョン管理システムでは、複雑なラベルを適用してから、これらのラベルを操作するスクリプトを作成できます。
バージョンの作業
Subversionのデフォルトの使用例は、リポジトリのチェックアウトからハードディスクにすべてのものをダウンロードし、作業してからコミットし、他の人が行ったすべての変更に直面した後、競合を解決します。GUIに表示されるこれらの概念。他の誰かがあなたのeg hello.docを編集するのを防ぎたいなら、あなたはそれをロックします：他の誰もそれを変更できるべきではありません。
私は本当にそのアイデアが好きではありません:(私見これは非常に悪い習慣です。比較と理解のために：ClearCaseではチェックアウトは多かれ少なかれロックに匹敵し、チェックインはコミットです（サブバージョンではチェックインはコミットのエイリアスです） 。これはClearCaseのデフォルトの使用例であり、サブバージョンのチェックアウトと同じハイジャックをサポートしますが、選択したファイルに対しても同様です。IMHOこれはかなりクリーンです。さらに、ClearCaseでチェックアウトを実行する場合でも、3つのオプションがあります：その他人々はそれに取り組んでいない可能性があります（例：ワードドキュメント）、本当に必要な場合は他の人々が取り組む可能性があり、「誰もがそれに取り組む可能性があります」（例：ソースコードファイル）だから...これがチェックアウト、ロック、コミットの意味ですSVNで。
コンポーネントとベースライン
RTCやClearCaseなどのツールでは、要素をコンポーネントにグループ化できます。これらのコンポーネントは名前空間の一部であり、ベースライン化することで独自のバージョンを取得するため、強力です。たとえば、コンポーネント「WordPress」はベースラインリリース4.53を取得します。これらのベースラインは、それ自体がオブジェクトであり、「テスト中」などのメタデータも取得できます。ただし、SVNにはこれがありません。そう... ：
タグ
SVN（およびWordPressサイトなど）では、「タグ」と呼ばれるディレクトリ全体に番号が付いたディレクトリが表示されます。回避策のアイデア。単に特定のリポジトリを取得して、それを（ファイルベースで）ディレクトリtags / 3.2.4にダンプします。それでおしまい。バージョン管理名前空間などとの関係はありません...単純なディレクトリ.... SIGH .....この種類のツールで構成管理を行うことは不可能です。そのため、スクリプトを作成してプロパティを割り当てたり、最もワイルドなことを実行したりできるメタデータオブジェクトではありません...単なるディレクトリ.............比較のためのRTCでは、 'このユースケースもサポートするための特定のベースラインのスナップショット。ClearCase UCMでは、特定のベースラインの新しいブランチ/ストリームを作成し、「表示」します。
枝
これは私の知る限りWordPress環境では使用されていませんが、おそらく私は間違っています。WordPressのリリースでこれを行って、変更を古いバージョンに移植するチームがあります。だから私は誰か他の人が知っていることを知りません。
これは名前空間ツリーに使用されます。2つのチームが同じコードで作業するようにするには、「英語で」\ team 1 \ hello.docおよび\ team 2 \ hello.docと言います。その後、両方のチームが作業を開始し、しばらくすると\ team 1 \ hello.doc \ version 51と\ team 2 \ hello.doc \ version 23ができます（したがって、チーム1は51バージョンを作成し、チーム2は23バージョンを作成しました）。これで、ブランチチーム1からブランチチーム2にマージする可能性があり、チーム2でマージを取得できますが、最後にチーム2にはチーム1（バージョン24）のすべての変更があり、個々のブランチには引き続きそれぞれの作業が表示されますそのうちの。
RTCおよびClearCaseではこれは使用されませんが、「比較」のために「ストリーム」と呼ばれるより高度なオブジェクトです。低い視点からは、これらを同じと見なすことができますが、実際のブランチでは、ブランチに多くのものが含まれます。したがって、現実の世界では、メモ、リリースノート、ドキュメントなどを作成する必要があります。これを強化するには、ストリームに「コード」だけでなく「変更」も含まれるため、RFC23のバージョンは34,32であることがわかります。そして56とあなたは別々にそれらを解放することができます。
物事を正しく設定したい場合は、私見をすべての人に1つ以上の個人的なストリーム/ブランチを与えます。だから彼らはそこからチェックイン/コミット、チェックアウトでき、誰も気にしない。誰かが準備ができたときにのみ、たとえばチームストリームやチームストリームがインテグレーションストリームに配信するなど、自分のコンテンツを「配信」します。「プロジェクトのテスト」はc：\ tempにあり、バージョン管理下にないため、5つのリリース時にのみ必要になる機能Xに一時的に取り組んでいる人のグループを持つことができないため、不利です。
理想的な世界とトレードオフ
\ team1 \ hello.docがあり、誰かが\ team2 \ ALSO hello.docにコピーした場合、これはBAaaaaadです。現在、IDが異なる2つの要素があり、ユーザーはそれらを同じであると考えていますが、システムはそれらを同じではないものとして扱います。これは「邪悪な双子」と呼ばれ、このような環境では絶対にこれを行うべきではありません。常にマージまたはブランチのベース。邪悪な双子を理解すれば、ブランチも理解できます（なぜ悪いのか：マージでは、それらは2つの異なるエンティティとして扱われますが、同じものとして扱われます）（または異なるシステムでは異なる種類の動作）。新しいユーザーが何かを台無しにした場合、これはほとんどそれです。「私はただhello.docを削除し、後ろにそれをコピーした」なんてこった
変更
SVNはこのサポートを提供していませんが、何らかの統合された変更管理/ ALMをサポートするためにSVNと統合できるツールがあります。ClearCase- UCMバリアントまたはRTCなどのツールでは、欠陥、RFC、チケットなどがないと1文字を変更できません... SVNではコミットしたときアトミックコミットの説明を入力できます。意味：「パッチ可能な」部分を変更するように努める必要があります。欠陥/変更ごとにアトミックコミットを実行して、ある程度の動作をさせます。（もちろん、その後、ClearCaseデータベースなどのネーミングツリーですべてがリンクされることはありません）（リリースノートを自動化したり、デプロイメントマネージャーである悪意のある人が大量の新しいコードセット、変更、リリース、試行を行うのを助けることができます）彼が実際にそれが何であるかについての洞察を彼に与えるための本当の道具なしでそれを一緒に混ぜる）。
SVNは変更管理をサポートしていないため、TRACを使用するように設定されたWordPress：http : //core.trac.wordpress.org/が存在するため、ご存知のとおりです:)
ClearCaseやRTCのような、変更がオブジェクトとして組み込まれている実際のツール（はい、プログラミング対象のツール）が見つからないため、TRACが存在しているように感じます。そのため、「その種の」変更セットを議論して送信するツールがあります（その概念もありません）。したがって、これらは「パッチ」であり、優れたシステムで期待されるメタデータのないファイルの集まりです（したがって、私は現在、不機嫌な状態です）。TRACの数は、いくつかの変更にリンクされているネーミングツリーの全体的なIDであるため、重要です。
変更の提供
これは別のブログ記事に書くものです。つまり、理想的な世界では、「配信」する変更（または別の概念）を選択し、ファイル、ディレクトリ（のバージョン）を気にする必要はありません。「RFC 3および5を提供する」だけです。これがClearCase UCMまたはRTCの動作方法です。SVN /ベースクリアケースでは、正しい決定を下したことを期待して一連のファイルを「コミット」します。それは大きな違いであり重要なことです。（これが、SVNが主にjira / clearquestなどと統合して使用され、この動作に到達する理由です）。パッチを適用しています...が配信されていません。1つのストリームから別のストリームに、ええと「パッチ」として配信されています。
外観
他のツールでは、これはSVNで異なっています。自分のものではないパーツからのコードがある場合、それを管理されている外部バージョンとして扱い、コアコンセプトに戻ることができます。つまり、一部は名前付けに関するものなので、名前空間の責任には該当しません。しかし、それが外部のものであっても、それはあなたの責任に該当します。
GUIでは、通常の「右マウス」にワークフローはありませんが、プロジェクト構造で定義されています。したがって、これは定義の一部です。
この概念を使用する場合、定義に必要なIEEE CMPで定義されます（下記を参照）。
統合とマージ
言われるように。SVNの背後にあるパラダイムは、ローカルでデータを取得し、作業を行い、コミットしてからs ***を取得することです。GUIでは、他のほとんどのツールとまったく同じツールを使用できます。ここでは、3者間マージ、2者間マージ、および自動的に解決できる競合と自動的に解決できない競合の違いを本当に理解する必要があります。この最後の1つは、2つのクラスに分類されます。ツールが良い最終結果を提案できるクラスと、最終結果がわからないクラスです。GUIについて質問しましたが、コマンドラインで、コミットする前に修正/マージする必要があるものに関する情報ファイルを取得しています。
ブログ記事にはもっとたくさんあります。（たとえば、ここでは実際に異なる選択をする必要があるため、オープンソース開発とエンタープライズ開発を比較し、マイスターと統合マネージャーを構築します）。
最後になりましたが、CMP
あなたが求めているのは、WordPressの構成管理計画です。これはIEEE文書です。意味：Googleで見つけた何百万もの構成管理計画のすべてが、CMPのIEEE仕様（いくつかのバージョン）に対して有効です。
RFC（HTTPなど）と同様に、IEEE CMPがあります。
この計画には、「外観の扱い方」や「名前空間の外観、アイテムの取得方法、アイテムの再現方法」などの定義されたセクション、役割、責任などが含まれます。
このCMPから、作業指示書を作成できます。ルールを知りたい人は誰でもCMPを読むことができます。
オープンソースのコンテキストでは、多くの場合、「構成マネージャー」の役割がありません。したがって、構成管理計画も見逃してしまいます。
パブリックRFC（URIやHTTPなど）とは異なり、IEEE標準ドキュメントに料金を支払う必要がありますが、Googleであれば、あちこちで見つけることができます。
配達通り
配達街では、チームが新しいビジネスのアイデアについて考えているでしょう。あなたは彼らのシステムに膨大な量の生産バグを抱えているメンテナンス部門を持っています。複数のチームが同じコードで作業することになります。各サブストリートには、要件を定義する要件チームがあります。機能チームと運用チームに分かれたアーキテクチャチーム（ユースケースは機能チームに移動し、非機能チームは運用チームに移動します）。単体テスト環境、受け入れ環境、負荷およびストレステスト環境、機能テスト環境、実稼働前テスト環境、実稼働環境で、さまざまなリリースを並行して実行することがよくあります。
それらすべてに、すべて相互にトレースされるバージョンがあります。
特定のテスト環境の1つのバージョンは、特定のRFCにリンクされている一連のバージョンにリンクされ、このバージョンは要件の特定のバージョンにリンクされています。次に、要件はテストセットの特定のバージョンにリンクされます。すべてがバージョン管理に該当します。
SVN / TRACを使用するWPでは、要件データベースと要件のバージョン管理データベースがまだ見つかりません。（インパクト分析を行い、1つの要件を変更した場合にどのコードが変更されるかを確認できるようにするため）（そして、新しいリリースでは、どの要件が変更されたかを印刷できます）。TRACの個々のアイテムがコメントでTRACの他の個々のアイテムにリンクされているのを見ました。また、コメント以外では、TRACアイテムとコードのトレーサビリティは確認できません。つまり、人々が頭の中で多くのことをしていることを意味し、アクティブなコミュニティやコア開発者に大きく依存しています。
しかし、これはトピックの笑顔をはるかに超えています
ALMのOSLC
この話についてもう1つ注意してください。これらすべてのアプリケーションライフサイクル管理ツール（ALM）の標準のパッケージが1つあればいいのではないでしょうか。誰かがそれを考え、今では標準があり、すべての概念がより高い抽象化レベルに置かれ、ツールに実装されます。Google：ALMのOSLC。（すべてのツールが互いに、そしてユーザーのために話すことができるように：抽象化レイヤーを理解することによってそれらすべてを理解すること）。
C / ALM
時間があれば、さらに一歩進んでください。世界は現在、C / ALMに向かっています。これは、プロセスとツールが統合された次世代の製品であり、プロセスが何であるかを不思議に思う必要はありません。この世代の最初の製品はRTCです。したがって、SVNをよく理解している場合、またはClearCase、Jira、Trac、ANT、アジャイル、RUP、iRUP、またはプロセス、バージョン管理、変更管理、ビルド管理などを理解している場合は、RTCを理解するためにそれらすべてが必要になります。 1つには、これらすべてが連携しており、これ自体がOSLCを介してインターフェイスしているため、これらの古いツールを「プラグイン」できるからです。
しかし今、私は本当に話題から外れています。