8

Subversionの機能を調べる際に、 svnbookの「分岐とマージ」の章の「基本的なマージ」セクションの「変更の取り消し」サブセクションで説明されているユースケースをテストしようとしました。私はバージョン1.6.4を使用していますが、そのセクションのテキストは両方のバージョンの本で同じです。

作業用コピーディレクトリで、ファイルtestcode.pyを編集し、編集ごとに1行追加し、編集ごとにコミットします。数回コミットした後、ファイルは次のように読み取られます。

this is my first import to trunk.  r1.

this is my first commit, first edit of testcode.py.  r2.

this is another edit of testcode.py.  r3.

this is an edit of testcode.py.  i'll get rid of this one.  r4.

this is another edit of testcode.py.  keeping it.  r5.

yet another edit.  keeping it.  r6.

リポジトリのリビジョン番号はファイルの行と一致しているため、/ trunk / testcode.py @ rNでは、ファイルの最後の行がrNで終わる行になります。私がやりたいのは、r4で終わる行を削除し、前後のすべてを変更しないようにすることです。

svnbookの「変更の取り消し」セクションの例に従って、コマンドを実行します

svn merge -c -4 file:///path_to_repos/trunk

これにより、競合が発生し（commitではなく、そのコマンドを実行すると）、merge-leftファイルには行r4までのすべてが含まれ、merge-rightファイルには行r3までのすべてが含まれます。つまり、過去の変更を削除する代わりに、コマンドはファイル全体をリビジョン3または4に戻し、後続のリビジョン（この場合は5および6）の変更を削除するように見えます。

svnbookの例を読むと、ユーザーはリビジョン303でコミットされた変更を元に戻し、結果を競合なしでリビジョン350にコミットします。実行したコマンドは、すべてを保持するsvnステータスがMのファイルを生成するはずです。 r4で終わる行を除く行。

私は本の例を間違って読んでいますか、例は間違っていますか、それとも私が気づかなかった他の形のユーザーエラーがありますか？

4

1 に答える 1

4

基本的な問題は、Subversion の diff アルゴリズムが、必ずしも直感的ではない方法でファイルの先頭と末尾の変更を処理することです。あなたの例はそのコーナーケースに当てはまりますが、実際の変更の大部分はそうではありません。一連のコミットの後、次のようなファイルがあるとします。

later commit (r5)
change to be reverted at beginning of file (r2)
initial commit (r1)
change to be reverted in middle of file (r3)
initial commit (r1)
change to be reverted at end of file (r4)
later commit (r5)

コミットをファイルの先頭または末尾 (例ではリビジョン 2 と 4) に戻そうとすると、競合が発生します。変更をファイルの途中に戻すと、期待どおりに機能します。

概念的には、変更セットは範囲が周囲の行によって制限されていると考えると役立つ場合があります。ファイルの途中での変更は、周囲の変更されていない行によって制限されます。ファイルの先頭または末尾での変更の範囲は、そのポイントが後でどれだけ移動されたかに関係なく、ファイルの先頭または末尾にまで及びます。

上記の例では、リビジョン 5 で追加された 2 行目は、リビジョン 4 のスコープのちょうど真ん中にあります。ここでリビジョン 10 を元に戻す競合が予想されるのと同じように、リビジョン 11 の変更はその途中で軽くたたくだけです。

...                    <-- Line unchanged by revision 10, bounding its scope
line from revision 10  <--\
line from revision 11     | Revision 10's scope
line from revision 10  <--/
...                    <-- Line unchanged by revision 10, bounding its scope

同じ理由で、ここで競合が発生することを予期する必要があります。

...                    <-- Line unchanged by revision 10, bounding its scope
line from revision 10  <--\
line from revision 11     | Revision 10's scope
<EOF>                  <--/ (No unchanged line bounding the scope this direction)

これは、Subversion のマージ プロセスを理解するための包括的な説明ではなく、ファイルの先頭と末尾の扱いが異なるように見える理由の概念的な説明としてのみ意図されていることに注意してください。

于 2012-07-19T21:24:07.910 に答える