SVNサブディレクトリのコミットとマージは有害なものとみなされますか？

Question

メインのSVNプロジェクトルートにいくつかの大きなサブプロジェクトがあります。
リリースブランチで作業しているときは、私のサブプロジェクトのみをコミットしてマージするのが主な点です。 （the section called “Common Branching Patterns”で説明したように）長寿命のリリースブランチのために

• 、唯一のルートにマージを実行します。

  しかし、同僚がこのreference to merging subdirectories in Version Control with Subversion（別名「SVNブック」）を指摘しましたブランチ、サブディレクトリではありません。

残念ながら、これは警告の範囲です。リンクされたセクションは説明もしません。

リリースブランチに有害なSVNサブディレクトリをコミットしてマージしていますか？
短命の機能ブランチはどうですか？

Answer 1

可能な説明の1つは、変更セットの一部を忘れる可能性があるということです。

チェックアウトしたサブディレクトリの外にあるカバーファイルをマージする変更セットがある場合、それらのファイルをマージする可能性は常にあります。例えば

、あなたがトランク上でこのようにコミットしている場合：

r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines 
Changed paths: 
    M /trunk/subdir1/main.c 
    M /trunk/subdir2/main.c 

Change some stuff 

そして、あなたは、あなたのブランチからsubdir1のチェックアウトを持っている「安定」、そしてあなたは、このようにR5を設定変更をマージすることができます：あなたが戻ってログを見れば

$ svn co http://example.com/svn/branches/stable/subdir1 
$ cd subdir1 
$ svn merge -c 5 http://example.com/svn/trunk/subdir1 . 
--- Merging r5 into '.': 
U main.c 
$ svn ci -m"Merged r5 from trunk" 

しかし、これは唯一、まだ改正5.さらに悪いの半分をマージしますが、それは今、これを表示します：

$ svn log -g http://example.com/svn/ 
... 
------------------------------------------------------------------------ 
r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines 
Changed paths: 
    M /trunk/subdir1/main.c 
    M /trunk/subdir2/main.c 
Merged via: r6 

Change some stuff 

コミット全体をマージしたように見えますが、実際にはいくつかのものしかマージしていないようです。もちろん、r6はstableブランチ上で1つのファイルだけが変更されたことを示しています。

------------------------------------------------------------------------ 
r6 | rich | 2009-04-16 22:28:16 +0200 (Thu, 16 Apr 2009) | 1 line 
Changed paths: 
    M /branches/stable/subdir2 
    M /branches/stable/subdir2/main.c 

Merge revision 5 from trunk 

誰かが、変更セットの一部だけがマージされ、残りの部分が実行する必要があることを覚えておいてください。サブディレクトリマージを使用しないと、この問題は回避されます。

以前のコミットをすべてマージしたくない場合があり、上記のシナリオはまさにあなたが意図したものです。その場合、おそらくあなたの意図を記述する良いコミットメッセージを追加するのが最善の方法です。

Answer 2

コミットに問題はありませんが、マージではSVNがマージされているものとマージされていないものを追跡します。

したがって、（SVNで比較されるデータセットのサイズに関して）将来のマージを簡略化するために、ルートでマージしたいと仮定します。

Answer 3

1.5より前のバージョンのサブバージョンでは、後でサブディレクトリをマージすると、残りのディレクトリツリーのマージが実際に複雑になります。 ディレクトリをマージした場合、svnはそのディレクトリ内のすべての変更を他のブランチに適用しただけです。すでにサブディレクトリをマージしてからメインディレクトリをマージしようとした場合、サブディレクトリ内のすべての変更はすでにターゲットブランチ内にあります（前にマージしたためです）。 Svnはこれらの変更が以前のマージからのものであることを知りませんでした。サブディレクトリをマージしようとしたときに「途中のものがある」ことが分かり、多くの競合が発生しました。

これを回避するには、前にマージしていなかったディレクトリだけをマージして、プロセス全体をはるかに複雑にする必要がありました。すでにマージしたサブディレクトリのリビジョンを正確に覚えておき、残りのディレクトリ/リビジョンの残りの変更だけを適用する必要がありました。これは混乱することがあります。常にブランチ全体をマージすることで、これはずっと簡単になりました。現在のバージョンのSubversionでは、以前のマージを内部的に追跡し、これらの問題を回避することができます。

サブディレクトリのコミットは問題ありません。 svnの場合、これはリポジトリの通常のグローバルリビジョンです。そのリビジョンでは、1つのサブディレクトリにのみ変更が加えられますが、svnでは、他のコミットと同様にリポジトリ全体の新しいバージョンです。

Answer 4

これは、ルートにのみマージすると、リポジトリのフォルダ/ファイルに設定されるsvn：mergeinfoプロパティの数が制限されることがあります。