私のチームは最近、ほとんどのSubversionリポジトリレイアウトに典型的な「トランク」ブランチを使用しないことを決定しました。いつでも、トランクが他のリポジトリで保持する従来の役割で機能する特定のブランチが常に存在することがわかりました。つまり、作業中の次のリリースを表す最も大きな番号のブランチが常にあります。したがって、トランクへのマージは単に不要なので、トランクを削除しました。
他の誰かがこれをしますか？
もしそうなら、あなたは何か賛否両論に気づきましたか？
あなたのチームがこれをしなくても、誰かがこのレイアウトについて何か考えを持っていますか？
あなたはプロモーションモデルについて話している -PERFORCEの論文はそれに関する問題を強調している-コードラインの変化する役割を伝え、ブランチ間で作業を移動する。
リストされた問題の私の見解の拡張：
1）コード行のポリシーの変更：
すべてのコード行には、それが書き留められて形式化されているか、開発者の頭の中で完全に暗黙的であるかにかかわらず、ポリシーがあります。たとえば、次のように定義されます。
トランクアプローチでは、ポリシーは固定されたままなので、書き留めやすく、コミュニケーションが容易になります（大規模なチームではより重要です）。
例：トランク：
バージョンブランチ：
タグブランチ：
開発者のプライベートブランチ：
プロモーションモデルがある場合は、メイン開発中に1つのポリシーがあり、リリースの準備中にポリシーを変更するときに全員に通知する必要があります。次に、行がリリースされたら別のポリシー（コード行用）を通知する必要があります。
プロモーションモデルは簡単に利用でき、ソース管理以外の作業方法に直接マッピングされます。しかし、大規模なチームを作り始めると、それは痛いです。
Linuxカーネルの開発を見ると、プロモーションモデルとトランクモデルの間の緊張がわかります。Linusのツリーはプロモーションです。マージウィンドウとrc/安定化期間の間のサイクルを通過します。しかし、Linux-nextと-mmは、よりトランクのようなラインを提供するために生まれました。
分散SCM/VCSはとにかく多少異なります。各開発には独自のツリーがあり、必要に応じて変更をプルするため、ポリシーをすべての開発者に配布する必要はありません。
オープンソースプロジェクトは、トランクから分岐した後、リリースを安定させるという面倒な作業を人々に強制できないという問題に悩まされています。したがって、プロモーションモデルは、機能に取り組むだけでなく、安定化の取り組みを強制する方法としてより重要です。
2）引越し作業：
開発者は、作業している行のポリシーがバグ修正のみに変更されたときに機能に取り組んでいる可能性があります。開発者は、作業コピーを別のコード行に切り替える必要があります。これは、使用しているSCMシステムに応じて、簡単なものから非常に難しいものまであります。開発者がトランクで作業している場合、作業は常にトランクで行われるため、この問題は発生しません。開発者がプライベートブランチまたは機能ブランチにいる場合、彼らの作業はトランク（およびリリース）にのみ影響を与えます。
機能がすでにチェックインされているが、現在のバージョンから遅れている場合は、その機能を削除する方法を検討する必要があります。この問題はトランクモデルにもまだ存在しますが、少し簡単に解決できる可能性があります。リリースのためにトランクから物事を選択します。これは、機能ブランチが役立つところですが、統合コストがかかります。
PERFORCEペーパーに関する私の問題は、主な利点、マージのオーバーヘッドの削減について言及せずに、プロモーションモデルをリバフすることです。実際、この論文は、「メインラインモデル」が「追加の管理オーバーヘッドなし」を課していると誤って述べています。これはばかげた主張です。「常にトランクにマージする」モデルは、まさにそれを意味します-マージする必要があるすべての人のオーバーヘッドがあります。次の状況（私たちが持っている）がある場合、これは無意味なオーバーヘッドです：
a）小さなチーム（5〜7人の開発者）全員が互いに叫ぶ距離内にいます。ブランチを作成する必要がある場合、コミュニケーションは問題になりません
と
b）実際には2つの主要なブランチ（本番ブランチと「開発中の次のもの」）しかないコードベース。たぶん、ブルームーンに一度は3つあります。
私のポイントは、状況に応じたものだと思います。「プロモーションモデルに問題がある」と言うのは、「OR/Mを使用しない」と言うようなものです。それはあなたの環境に依存します。
Subversionは両方のアプローチを可能にします。トランクは必需品ではなく、慣例です。持っている場合、いくつかのツールはより簡単に動作します（たとえば、Gitの移行ツール）。持っていない場合は手作業でやらなくてはいけませんが、日常の仕事で気付くようなことは考えられません。
私は最近、Subversionリポジトリにあるプロジェクトの作業を開始しました。リポジトリを作成した人は誰でも特定のレイアウトに従わなかった-彼らは単にリポジトリのルートにすべてを詰め込んだ（トランク/、ブランチ/、そして確かにタグ/はない）。作業するブランチと他のもののためのいくつかのタグを作成したかったのですが、適切なレイアウトに従わないSubversionリポジトリでそれを行うのがいかに難しいかを理解しました。
私たちはそうします-ある種。トランクは使用しませんが、プロジェクトのリリースごとに新しいブランチを作成します。この「タグ付き」ブランチは、各バージョンのトランクになり、変更を古いリリースにマージすることでバグ修正をバックポートします。
それは私たちにとってはうまく機能しますが、私たちのプロジェクトにはたくさんのサブプロジェクトがあります。
IME、一部の環境では、トランクは修正や変更を交換するのに適した場所です。つまり、誰もが自分の修正をトランクにマージし、他の人の修正をトランクからマージします。多くの独立したプロジェクト間で多くのコードが共有され、それらすべてのプロジェクトが共有コードに貢献している環境で非常に役立つことがわかりました。
ただし、環境は異なる場合があります。