SubversionでGit Flowを使用する際の障害

私の職場のチームは、VCSとしてSubversionを使用して新しいプロジェクトを開始しています（この質問の目的のために、これは固いものと考えることができます）。私たちはまだプロジェクトの初期段階にあり、分岐モデルについて合意しようとしています。以前のプロジェクトは非標準バージョンモデルに基づいていたため、既存のリリースのホットフィックスとパッチを管理するときに問題が発生しました。

さまざまな分岐モデルがかなり複雑であることがわかりましたが、私がかなり明確に理解しているモデルの1つはgit flowです。Subversionでこれのバリエーションを実装するのがどれほど難しい/望ましくないか知りたいです。明らかに、ブランチで協力している人々の点でいくつかの違いがあります。機能ブランチはローカルリポジトリに限定するのではなく一元化する必要がありますが、モデルの他の概念は、私が理解しているようにSubversionで再現可能でなければなりません。

このアプローチの欠点または課題は何でしょうか。私が聞いたのは、SVNではGitに比べて「マージは高価です」ということです。しかし、これが実際に何を意味するのか、それがブランチモデルのようなgitフローを使用する能力にどのように影響するのかについては、完全には明らかではありません。

このアプローチの最大の懸念は何でしょう。Subversionでより自然な同様の明確なアプローチはありますか？

Gitflowは、ソースコードのバージョン管理と分岐のベストプラクティスに基づいています。これに関する非常に優れた記事は、高度なSCM分岐戦略です。

リンクされた記事でヴァンスが述べている点は、ブランチごとに役割が異なるということです。彼は次の役割を特定します。

1. メインライン（ここからのすべてのブランチ）
2. 開発（開発作業が行われる場合）
3. メンテナンス（メンテナンス作業を行う場所）
4. 蓄積（リリースに向けて準備する）
5. パッケージ化（リリース用のビルドのパッケージ化）

gitflowでは、これらは次のとおりです。

1. 発展させる
2. 機能ブランチ
3. 修正プログラムのブランチ
4. ブランチをリリースする
5. 主人

分岐に関する記事は、Perforceを念頭に置いて書かれました。PERFORCEは集中管理されたVCSであり、svnと同様です。彼が説明する分岐のパターンは完全にsvnに対応しています。

実現するための鍵は、gitflowがどのようにsvnに移植されるかではなく、分岐の同じ基本概念と分岐の役割を異なるVCS構造に適用する方法です。

私はその記事を読むことを強くお勧めします。私はそれをあまり信用できません。そこに記載されている方法は、svnを簡単にマッピングできると思われるトランク/メインラインビルドの哲学に基づいています。