Subversion - 外部のない一般的なフォルダを共有する

Question

私のSWグループは、私たちの姉妹サイトがすでにそれを使用しているため、私たちのソース管理システムをMicrosoftがサポートしていないVisual Source SafeからSubversionにアップデートしようとしています。 VSSでは内部リンクで直接行うことができる共有コードが多数あります。複数のプロジェクトを使用するには、これらを共有フォルダに移動する必要があります。外部を使用してこれらを導入することは可能ですが、SVNアーキテクチャーにはややリスクがあります（ただしサードパーティーのコードや変更されないものにも使用する予定です）。とにかく私はどこにも書かれていない解決策を考案しましたが、私たちは皆考えていましたので、他の人が何を考えているのか、落とし穴があるのか​​見てみました。

私は外部とは対照的に、この "共有内部"フォルダと呼んでいます。ある言語（この場合はC++）の汎用ライブラリファイルを含むリポジトリルートにCommon_Codeというディレクトリがあるとします。今私はトランク/ブランチ/タグでMyProjectを作成し、私のプロジェクトのサブディレクトリに共有フォルダを入れたいと思います。ですから、Common_CodeからMyProject/trunk/Common_Codeに分岐する通常のSubversionブランチを作成します。 さまざまなチームメンバーがトランクから分岐することで、MyProjectで作業します。 BobのブランチはMyProject/branches/Bob_Workingのようになり、サブフォルダはMyProject/branches/Bob_Working/Common_Codeに分岐します。これは実質的に共有フォルダのブランチのブランチです。

ボブが完成すると、彼はトランクに再びマージします。これは、ルート共有フォルダから「内部ブランチ」を作成した可能性のある他のプロジェクトに干渉することなく継続されます。最終的には製品をリリースしますが、他のプロジェクトに役立つCommon_Codeにいくつかの一般的な変更を加えたことがわかります。したがって、グループのレビューの後、プロジェクトのCommon_Codeバージョンを最初に取得したルートバージョンにマージすることに同意します。これにより、リリースの共有コードを更新する必要がなくなり、変更を他の会社と共有する必要がなくなります。

これはコードをネイティブに共有するシンプルで柔軟な方法のようです。私は2つの可能性のある制限を見る。第一に、リポジトリ間では機能しません。その場合は、外部を使用する必要があります。第二に、マージ後の最初のブランチを削除することはできないので、-reintegrateを使うとは思いません。通常のマージバックが受け入れられるのか、私たちのTortoiseクライアントがサポートしているのかまだ分かりません。

Answer 1

多くの研究と議論の末、コードを共有する外部メソッドを使用することに決めました。私は結論レポートを掲載しているので、他の人たちが私たちが特定できた正当性から利益を得ることができます。もし人々がこれが他の人にとって有益だと思うなら、それが見えるように投票してください。

私は姉妹サイトの外部の方針を見直した後、これらの2つの方法の間の主要な基本的な違いを抽出しようとしました。私が最初に気付かなかったことの1つは、共通フォルダにトランクとブランチを持たなくても実行可能な外観を更新する方法が記述されていることでした。

外部メソッドでは、必要に応じて共通のフォルダリビジョンにペグすることができますが、一般的なコードを変更する場合は、アンインストール、最新のrevへのローカル更新、追加独自の変更を加え、共通フォルダにコミットします。言い換えれば、共通の領域では誰もがトランクから外れますが、ペグは変更を加えるまで影響を受けません。これは、プロジェクト固有のコードとそれが使用する共通コードの間の分離レベルを追加することで共通を同期させます。

二重ブランチを使用すると、共通コードをローカルで独立して変更することができますが、後で共通トランクにマージすることを忘れないようにする必要があります。つまり、プロジェクト特有の共通コードをいつでも同期させて保存しますが、共通バージョンと共有共通バージョンのプロジェクトバージョンを分離するレベルが追加されます。

実際にこのような違いが生じるのは、外部に対して、まずコミット時に共通のコードをマージしてから、プロジェクトのトランクにマージすることです。しかし、他のプロジェクトは、以前のバージョンに縛られているので、単独で放置されています。 一方、二重分岐を使用すると、まずプロジェクトトランクにマージし、後で共通コードをマージすることができます（2回目のマージ）。あなたはその場合どちらの順序でも行うことができますが。

プロジェクトにどちらの方法も選択させるという考えを示しましたが、誰かが均一なポリシーにできるだけ固執する利点を正しく指摘しました。私が今知っていることを考えれば、私は1つを選択しなければならない場合は、共有メソッドがリポジトリ全体で一貫性を維持するようにしなければならないと思われるので、外部メソッドを使用します。特定のプロジェクトからのそのレベルの独立性を与えることによって、人々は共通のコードが十分に一般的なままであることを確認することを考えるように強制します。誰かが実際にプロジェクト用に調整したければ、必要なファイルの個別のコピーを作成し、プロジェクトディレクトリで実行する必要があります。結局のところ、元のディレクトリに戻ってくるので、そのドアを開いたままにしておく必要はありません。