使用に関するガイド WP SVNと IDE クライアント？
公式のWPリポジトリを扱うためのドキュメンテーションはもっぱらコマンドラインの使用についてです。私はそれに対して偏見はありませんが、私はVCSに関する経験がほとんどなく、近いうちに2つ（または3つ）の異なるものを見つけて使用する必要があります。
だから今のところ私はIDE（NetBeans、PHPStorm）のVCS統合機能を使っています。そのため、細かいことや適切に処理する方法について私は混乱しています。
IDEまたは他のGUIベースのツールと一緒に公式のSVNリポジトリ（または少なくともSVN全般）を使用することに関する優れた記事/投稿/ガイドがありますか？コンソールで難解な行を入力するのではなく、概念とワークフローに焦点を当てたもの。
私は現時点では（広く推奨されている）TortoiseSVNを使用していませんが、非常に 豊富なマニュアルがあり、オンラインおよび複数の言語でダウンロードできます 。
それ自身の言葉で：
この本は、データを管理するためにSubversionを使いたいが、コマンドラインクライアントを使って操作するのに不快な、コンピュータを熟知した人々のために書かれています。 （ はじめに ）
この文書はTortoiseSVNクライアントの日々の使用法について説明しています。これはバージョン管理システムの紹介ではなく、Subversion（SVN）の紹介でもありません。おおよそ何をしたいのか知っているときに頼る場所のようなものですが、それをする方法をかなり覚えていないでください。 （ 第4章日常使用の手引き ）
私が探していたものはほとんど読んでいます。
私はこの回答を少し話題から外れたGRINにしたので、この回答をブログ記事にします。 http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ 6章で私はSVNの説明をしましたEclipseですが、おそらく何か他のものを探しています。
私がここで作った話はあなたのコメントについてでした
「だから今のところ、IDEのVCS統合機能（NetBeans、PHPStorm）を使っています。これにより、適切に行うための詳細や方法について混乱することがよくあります。」 「コンソールで不可解な行を入力するのではなく、概念とワークフローに焦点を合わせたもの」
もう少し頻繁にSVNをもっと広い文脈で説明したいと聞いたことがあります。最初に「プログラミング言語」を説明してからPHPを説明すると、PHPをよりよく理解できます。この場合、Configuration Managementを最初に、次にSVNソリューションを理解します。
ここに何かを入力します。トピックから外れている場合や必要ない場合は削除します。
------------ 8 <----------------
Eclipse PDPをインストールする場合、私はこれを書いています：[ http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ =]
＃6までスクロールダウンする場合、Eclipseでcollabnetサブクリップをインストールする方法を簡単に説明します（基本的には、サーバーを選択してすべて選択してインストールします）。
あらゆるバージョン管理ツールを備えたEclipseでは、バージョン管理のコマンドは常に右クリックで「TEAM」をクリックします。プロジェクトを切り替えることができるため、複数のバージョン管理ツールをサポートでき、ほとんどのコマンドはGUIを介したツールよりも使い慣れています。
プラグイン
ご存知のように、新しいWordPressプラグインプロジェクトでは、WordPress.orgから（メールボックス内で）svnの場所を取得し、最新のコードと安定したリリースの「タグ」コピーにトランクを使用します。 （非常に基本的なCMパターン）。これは一見したところです。
したがって、プロジェクトはTRUNKにリンクされます。そして、あなたは単にそれにコミットすることができます。これは作業する場所です（ただし、リリース元ではありません）（readme.txtで「trunk」を最終コードの場所として指定しない限り）。
さらに、WordPress/wp-includesおよび/ wp-adminをライブラリとしてEclipseプロジェクトに含めることができます。これにより、関数を検索して非推奨の関数を確認できます。これらは書き込み可能ではないため、バージョン管理下にはありません（！）。これはクライアント側からであるため、バージョン管理プロジェクトに実際にリンクする「外部」ではありません。
安定したバージョンができたらすぐに、スタッフを選択して「チーム」と「タグ/ブランチを作成」を右クリックすると、WordPress svnロケーションが開き、タグディレクトリを選択して新しい番号を入力できますそして、あなたの新しいバージョンはライブです（これはおそらくこれを読んでいる人に役立つでしょう）。プロジェクトのルートを選択するのではなく、他のすべてのものを選択する必要があることに注意してください。ルートの下にあるすべてのものを/ tagディレクトリに入れたいものではありません。
いくつかのスクリーンショットの投稿を参照してください。
http://wp.leau.co/files/2011/02/image_thumb17.png
WordPress自体の貢献者
あなたが貢献者であれば、上記と同じものを使用できますが、行った変更から「パッチ」を作成します。 「パッチ」は、CMの世界における概念です。 Subversionはこれまたはjazz RTCを提供します。 WordPressトランクにまだ適用されていないパッチがある場合は、[パッチを適用]を右クリックしてパッチを適用できます。
トランクに直接コミットする人もいます。
WordPress自体は「読む」
（Subversionコードの）トランクに/ LATESTバージョンのチェックアウトを含むプロジェクト「WordPress」を作成し、チーム>チェックアウトで再度作成します。
個人的にはこれを行いませんが、最新のコードのエクスポートを（強制的に）使用して、最新のWordPressバージョンのディレクトリを取得します（バージョン管理の対象外です）
一般に
VCSとSVNに関する質問にある程度の経験があるため、基本的にすべてのバージョンツールは、名前の付け方の概念に関するものです。または、最良の名前空間を持っていると言った方が良いでしょう。 CVS、Git、RTC、ClearCase、SourceSafeなどのほとんどのコマンドを、このネームスペースに関する概念にマッピングできます。他のツールの使用経験があるので、もう少し広範です：
新しい人はしばしば特定のコマンドや特定の機能を盲目に見つめますが、名前空間に必要なすべての要素を配置するための最適なオプションを提供することが中核です。
これは基本的にこれらのツールのコア機能であるため、「バージョン管理」という用語は間違っています。実際には名前空間マネージャーです。
あなたが持っているなら
/ project A/department B/Team C/Member D/Stream E/Component F/Element G/Branch H/Branch I/Version J
「モノ」ごとに一意の名前を作成できます。上記は、名前空間ツールの1つを使用して特定の目的に必要な名前空間の実装です。
この世界のほぼすべての概念をこれにマッピングできるため、カスタム名前空間/分類法をサポートできる方法は、ツールの機能に依存します。だから...それは本当に何百もの異なるツールの設計者が行った概念と選択に依存します。
優れたツールでは、クリックしてこの完全なtaxonomyを1つのツリーで表示したり、1つのツリーでズームインしたりできます。
それが核です：複雑さを管理するのに役立つツール（ウィキペディアの複雑さを参照してください： http://en.wikipedia.org/wiki/Complexity ）カスタム分類を管理するための優れたツールを提供することにより。分類法を作成し、その設定方法を考える人は、構成管理計画と呼ばれる計画を作成する構成マネージャーであり、これを最初に考えます。
WordPressでカスタム分類法のセットを作成するように依頼する人がいることを想像してください。この分類法は、会社のすべてのオブジェクトを表します。あなたは多くのデザインの選択をすることができ、誰もがいくつかの選択に基づいて何か他のものを生成します。一部にはより多くの機能が含まれ、一部はより単純で、より複雑な機能はすべて異なる決定を下します。これが「これらのツール」です。したがって、バージョン管理に関するツールレベルでの議論はまったく理解できないため、理解できません。
PHPでは、ディレクトリを使用して階層を作成する名前空間を作成し、オブジェクトおよびメソッド内で命名規則を適用できます。階層に配置した1つのファイルを取得する場合は、さらに一歩進んでください。後ろに1つ追加し、その後ろにバージョン番号を配置します。チームAがファイルのバージョン4で作業し、チームBがそのバージョンで作業する必要があるため、それでも十分ではありません。したがって、別の/を追加し、ブランチIDを追加します。これは、名前空間を構築する方法です。ツールによっては、好きなだけ夢中になることができます。
しかし、それは次のことを意味します。誰かが「ドキュメントZはどこにあるのか」と尋ねてきたら、答えを出すことはできません。バージョン管理システムには「ドキュメントZ」が存在しないためです。彼が「ドキュメントZバージョン5」と言ったとしても、チーム1ブランチの「ドキュメントZバージョン5」またはチーム2ブランチの「ドキュメントZバージョン5」を意味するため、引き渡すことはできません。それはすべて命名に関するものです。 「ドキュメントZバージョン5」は、定義された名前空間での正しい命名方法ではありません。
Subversionでは、これを行うことができるのは限られているため、理解しやすくなっています。これに一致するいくつかの概念：
"バージョン"
バージョンは、特定の要素の改訂版です。例えばwp-config.phpバージョン5。ClearCaseなどのツールでは、要素の個々のバージョンを表示して、個々のファイルを「コミット」することもできます（ただし、アトミックコミットまたはセットの変更など）.
Subversionの処理バージョンはより制限されています。
- ローカルで行った一連の変更は「commit」になります。つまり、「変更」の完全なセットがアトミックにコミットされ、ベース全体が新しいバージョン番号を取得します。これは、WordPress Subversionサイトに表示されるバージョン番号です。
- そのため、1つのファイルに対してローカルでさらに変更を加えて、それらをすべてクリアケースのように単一の新しいバージョンとして扱うことはできません。その1つのファイルまたは他のファイルに対してローカルで行ったすべての変更は一度に送信され、その「一意の新しい名前」を取得します。
- リポジトリ（権限）にアクセスできない場合は、一連の変更を行い、それらを「パッチ」に保存できます。次に、そのパッチを、統合マネージャーや、リポジトリに適用するビルドマネージャーなどに送信できます。などのツールRTCは「パッチ」もサポートしています。したがって、ある人がパッチを作成し、別の人がパッチを適用します。 Wordは「パッチ」を意味するため、コード開発のデフォルトのユースケースではなく、これを本当に考慮する必要があります。
- / branch N/hello.doc/version 25の代わりに、/ branch N/hello.doc/LATESTや/ HEADなどのラベルもあります。一部のバージョン管理システムでは、複雑なラベルを適用してから、これらのラベルで動作するスクリプトを作成できます。
バージョンの作成
Subversionのデフォルトのユースケースは、リポジトリからすべてのものをハードディスクにダウンロードするだけですcheckout、その上で作業してからcommmitして、他のすべての変更に直面しますその後、競合を解決します。 GUIに表示されるこれらの概念。他の誰かがあなたの編集もしたくない場合hello.docその後、LOCK it意味：誰もそれを変更できないはずです。
私は本当にその考えが好きではありません:(私見は非常に悪い習慣です。比較と理解のために：ClearCaseではcheckoutはロックとcheckinにほぼ匹敵します=はコミットです（Subversionのチェックインはコミットのエイリアスです）。これは、ClearCaseのデフォルトのユースケースであり、Subversionと同じhijacksもサポートしていますcheckoutさらに、選択したファイルについては、これははるかにクリーンです。さらに、ClearCaseでcheckoutを実行しても、次の3つのオプションがあります。本当に必要な場合に動作するかもしれませんし、「誰でも動作するかもしれません」（例えば、ソースコードファイルで）だから...これはSVNでのチェックアウト、ロック、コミットの意味です。
コンポーネントとベースライン
RTCやClearCaseなどのツールでは、要素をコンポーネントにグループ化できます。これらのコンポーネントは名前空間の一部であり、ベースラインを作成することで独自のバージョンを取得するため強力です。例えばコンポーネント「WordPress」はベースラインリリース4.53を取得します。これらのベースラインは、それ自体がオブジェクトであり、「テスト中」などのメタデータも取得できます。ただし、SVNにはこれはありません。そう... ：
タグ
SVN（WordPressサイトなど）では、 'tags'と呼ばれるディレクトリ全体に番号付きのディレクトリが表示されます。回避策。特定のリポジトリを取得し、それを（ファイルベースで）ディレクトリ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では、これは使用されませんが、「ストリーム」と呼ばれるより高度なオブジェクト（比較用）。低い視点からは、これらを同じと考えることができますが、実生活にいるときは、ブランチにはたくさんのものが含まれます。したがって、現実の世界では、メモ、リリースノート、ドキュメントなどを作成する必要があります。これを強化するには、「コード」だけでなく「変更」もストリームに含める必要があります。 56そしてそれらを別々に解放できます。
私見を正しくセットアップしたい場合は、すべての人に1つ以上の個人的なストリーム/ブランチを提供します。したがって、彼らはそこからチェックイン/コミットおよびチェックアウトすることができ、誰も気にしません。誰かが準備ができたときだけ、例えば、チームストリームとチームストリームは統合ストリームなどに配信されます。WPでは、リリースはブランチである可能性がありますが、通常の人向けです。すべて同じブランチで動作します。 「プロジェクトのテスト」はバージョン管理下ではなくc：\ tempにあるため、リリース5でのみ必要となる機能Xで一時的に作業するグループを持つことはできません。
理想的な世界とトレードオフ
\ team1\hello.docがあり、誰かが\ team2 \にhello.docをコピーすると、これはBAaaaaadであることがわかります。以来、ユーザーは同じだと思っているが、システムはそれらを同じではないものとして扱う、異なるIDを持つ2つの要素を持っています。これは「邪悪な双子」と呼ばれ、このような環境では決してこれを行うべきではありません。ブランチのマージまたはベース。邪悪な双子を理解するなら、あなたは枝を理解します（なぜこれが悪いのか：マージではそれらを同じものとして扱いたいのに2つの異なるエンティティとして扱われるため）（または異なるシステムでの異なる種類の動作）。新しいユーザーが何かを台無しにした場合、これはほとんどそれです。 「hello.docを削除してコピーして戻しました」argh
変更
SVNはこのサポートを提供していませんが、何らかの統合変更管理/ ALMをサポートするために統合できるツールがあります。 ClearCase- UCMバリアントやRTCなどのツールでは、欠陥、RFC、チケットなどがなければ1文字を変更できません。SVNでは、コミットアトミックコミットの説明を入力します。意味：言い換えれば、「パッチ適用可能な」部分に変更を加えるようにする必要があります。つまり、欠陥/変更ごとにアトミックコミットを実行して、ある程度その動作を持たせる必要があります。 （もちろん、ClearCaseデータベースなどのネーミングツリーでリンクされているわけではありません）（そのため、リリースノートを自動化したり、デプロイメントマネージャーである貧乏人が大量の新しいコード、変更、リリース、試行を手伝ったりすることができます実際のツールを使用せずに混ぜ合わせて、実際に何であるかについての洞察を与えます）。
SVNはTRACを使用するように設定された変更管理WordPressをサポートしていないため、 http://core.trac.wordpress.org/ そこに住んでいるのでご存知の通り:)
TRACがあるのは、ClearCaseやRTCのような、オブジェクト（プログラム対象のオブジェクト）として変更が統合された実際のツールがないためです。そのため、「変更」セットを議論し、提出するツールがあります（その概念もありません）。したがって、これらは「パッチ」であり、優れたシステムで期待されるメタデータを含まない単なるファイルの束です（したがって、私は現在Grumpy状態です）。 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で見つけた何百万もの構成管理計画は、IEEEが指定した（複数のバージョンの）CMPに対してすべて有効です。
（HTTPなど）RFCと同様に、IEEE CMPがあります。
この計画には、「外部の処理方法」や「名前空間の外観、アイテムの取得方法、アイテムの複製方法」、役割、責任などの定義済みセクションが含まれます。
このCMPから、作業指示書を作成できます。ルールが何であるかを知りたい人は誰でもCMPを読むことができます。
オープンソースのコンテキストでは、多くの場合、「構成マネージャー」の役割がありません。そのため、構成管理計画も見逃しています。
パブリックRFC（URIやHTTPなど）とは異なり、IEEE標準ドキュメントの料金を支払う必要がありますが... Googleの場合は、あちこちで見つけることができます。
配信ストリート
配達通りには、新しいビジネスアイデアについて考えているチームがいます。システムに膨大な数の生産バグを抱えるメンテナンス部門があります。複数のチームが同じコードで作業することになります。各サブストリートには、要件を定義する要件チームがあります。機能チームと運用チームに分かれたアーキテクチャチーム（ユースケースは機能チームに、非機能チームは運用チームに分けられます）。多くの場合、ユニットテスト環境、受け入れ環境、負荷およびストレステスト環境、機能テスト環境、実稼働前テスト環境、および実稼働環境で、異なるリリースが並行して実行されます。
それらはすべて、互いにトレースされるバージョンです。
特定のテスト環境の1つのバージョンは、特定のRFCにリンクされた一連のバージョンにリンクされ、このバージョンは要件の特定のバージョンにリンクされます。次に、要件はテストセットの特定のバージョンにリンクされます。すべてがバージョン管理下にあります。
SVN/TRACを使用したWPには、要件のデータベースと要件のバージョン管理データベースがまだ見つかりません。 （そのため、1つの要件を変更した場合に影響分析を行い、どのコードが変更されるかを確認できます）（新しいリリースでは、どの要件が変更されたかを印刷できます）。コメントでTRACの他の個々のアイテムへのリンクが作成されているTRACの個々のアイテムを見ました。また、TRAC項目とコメント以外のコードとの間のトレーサビリティも確認していません。つまり、人々は頭の中で多くのことを行っており、その多くが脳にあるため、活発なコミュニティやコア開発者に大きく依存しています。
しかし、これは話題から大きく外れていますgrin
ALMのOSLC
この話にもう1つ注意してください。これらのアプリケーションライフサイクル管理ツール（ALM）のすべてに標準のパッケージが1つあるとしたら、いいことではないでしょうか。誰かがそれを考え、現在は標準があり、すべての概念がより高い抽象化レベルに置かれ、ツールに実装されます。 Google：ALMのOSLC。 （すべてのツールが相互に、またユーザーと対話できるように、抽象化レイヤーを理解することですべてを理解できるようにします）。
C/ALM
時間があれば、さらに一歩先へ：世界はC/ALMに向かっています。C/ ALMは、プロセスとツーリングが1つの統合されたものであり、プロセスが何であるかをもう気にする必要のない次世代製品です。この世代の最初の製品はRTCです。したがって、SVNを十分に理解している場合、またはClearCaseまたはJiraまたはTracまたはANTまたはAgileまたはRUPまたはiRUPを理解している場合、またはプロセス、バージョン管理、変更管理、ビルド管理のことを理解している場合、RTCこれらはすべて1つにまとめられているためです。これらはすべて一緒になっており、これ自体がOSLCを介してインターフェイスしているため、これらの古いツールはすべて「プラグイン」できます。
しかし、今私は本当に話題から外れています。
Windowsを使用している場合は、TortoiseSVN（http://tortoisesvn.tigris.org/）を試すことができます。 IDEとは統合されていませんが、Windowsエクスプローラとは統合されているため、コードを右クリックしてチェックイン/チェックアウトすることもできます。
私が見た中で最高のGUIは http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/ です
Mercurialに基づいた素晴らしいビジュアルチュートリアルがここにあります http://hginit.com/
これの多くは、IDEがsvnとgitの統合により、物事を簡単に行えるかどうかに依存します。たとえば、Eclipseには多くのツールがありますが、ultraedit（以前使用していた）には奇妙なバージョンがありますGUIとシステムを制御します。
トピックは退屈症候群に苦しんでいます。少なくとも、このために詳細を学ぶのは難しいです。このトピックに関するyoutubeビデオを見ると、学習曲線x100が本当に助けになることがわかりました。