v1.5より前のSVNでのマージに関する不便さは、メタデータの欠如がもはや問題にならなくなった今では時代遅れになっていますか？

私はSVNを使い始めましたが、DVCSツールと比較してSVNでのマージは非常に難しいと多くのソースが言っています。最新の質問私はSEにここに見つけることができる2012年からです。

時々、v1.5より前のSVNにはメタデータがなかったが、SVNは現在バージョン1.8.9であるという理由が言及されています。

SVNがv1.5よりもはるかに成熟していることを考えると、特にSVN 1.5を使用しなかったため、前述のメタデータの欠如に悩まされていないという事実を考えると、SVN に対するこれらの議論にはまだ多くの妥当性がありますか？

DVCSには完全に異なるアプローチがあり、それがより望ましい場合が多いことを理解していますが、何らかの理由でSVNを「必要」とする人にとって、マージはもはや「地獄」ではありませんか？

これは、罰金の作品あなたが単純な場合に固執するならば、しかしない、いくつかの複雑なものがあります。

私が考えることができる制限：

• 関係するブランチの1つにある場合にのみ、最新の祖先を見つけることができます。したがって、を作成branches/thisしbranches/thatてからの両方trunkにマージbranches/thisしてからにマージしようとするとbranches/that、何をすべきかわかりません。つまり、ブランチをマージできるのは、その親に対してのみです。2つの機能ブランチを開始し、後で機能が相互に依存しており、それらを結合する必要があることに気付いた場合、これに遭遇する可能性があります。

• 名前の変更を追跡できると主張していますが、一方の側でファイルが移動され、他方の側で変更されたときにブランチをマージしても、マージする適切なファイルが常に見つかるとは限らず、必要な情報をどこにも残さないため、手動で修正するのは面倒です手。

• 追加されたファイルは、後のマージで誤った競合を引き起こすことがあります。

• Subversionには個別のブランチの概念がないので、プロジェクトのサブツリーのみをマージでき、それは非常に迅速に大きな混乱につながる可能性があります。完全なブランチを常にマージするように注意することを強くお勧めします。残念ながら、何らかの理由で、マージ情報プロパティがサブディレクトリに表示されることがありますが、それらが不要に見え、ブランチ全体に対して正しくマージされた場合でもです。

• 最後になりましたが、遅くなります。大規模なプロジェクトのマージには、ほとんどのDVCSが1秒未満で実行できる場合に数分かかることがあります。

私の経験から、SVNのマージはバージョン1.6で「修正」されました。私はMercurialとSVNの両方で仕事をしていますが、SVNのバージョン1.6以降では、両方のプラットフォームでマージはほぼ同じ量の仕事のようです。1つの例外は--reintegrate、SVNを使用してブランチからトランクにマージするときにオプションを提供することを忘れないでください。

これは私の運用経験です。SVNの内部については何も知りません。