svnは前のコミットを上書きできるのはなぜですか？

Question

2人のユーザーが同じファイルで作業していて、user Aがuser Bの前にコミットすると、警告なしでuser Aのコミットが上書きされます。

これはなぜですか、これを防ぐ方法はありますか？

これはちょうどここで起こりました。はuser Bのコミット後に行った変更にパッチを当てて修正する必要がありました。

これは危険なようですが、特定のファイルのベースが更新されていないことをsvnに伝えることはできません。

Answer 1

が明示的にそれを要求しない限り、SVNは単にuserAをコミットしません。それは偶然に起こることではありません。

userBが自分のファイルをコミットしようとすると、SVNはエラー

が表示されます今userBはSVNの更新を行う必要があります。 SVNは本当にASCII（テキスト）ファイルで動作するように設計されて

ASCII：これは、ファイルの種類に応じて、今行くことができる2つの方法があります。 SVN更新を行うと、userAの変更をuserBのファイルに「マージ」します。つまり、userAで変更された行は、userBの作業コピーに変更されます。 userBは実際にはuserBがしようとしていた変更を壊さないようにマージを確認する必要があります。両方のユーザーが同じ行を変更した場合、競合にフラグが立てられます。 userBは競合を確認し、何を達成しようとしていたのかを把握し、両方のユーザーの変更を保存するために何をすべきかを手動で決定する必要があります。

バイナリ

SVNは本当にバイナリファイルをマージするように設計されていません。マージが適用可能な場合、その特定のバイナリ用に実際にカスタムビルドされたツールに依存する必要があります。 userBが更新を実行すると、競合が発生し、userBは差異を確認してファイルをマージできなくなります。特定のバイナリタイプでマージツールが利用できない場合、userBはuserAのバージョンを受け入れ、そのバイナリを生成するツールを使用してバイナリへの変更を再度行う必要があります。

userBは、ワークフローのコピーを保存してsvn updateを実行し、コピーを復元してコミットすることで、このワークフローを回避できます。これはuserAのすべての変更を元に戻します。このASCIIのケースでは、特にこれはダッシュ移動と呼ばれます。バイナリの場合、2人のユーザーが実際に通信し、2人のうちのどちらが自分の作業をやり直す必要があるかを決定する必要があります。

SVNでバイナリファイルを扱う場合、大きな問題になります。解決策は頻繁にコミットするか、acquire lock機能を使用することです。また、ファイルを処理する直前にはsvn updateに、変更が完了したらすぐにsvn commitにしてください。

userBがマージを拒否して大量の作業を破棄した場合は、いつでもuserBのコミットに復帰して再試行するように指示できます。