回答:
これは、バージョン管理システムにコミットすると、コミットしたいすべてが入ってくるか、何も入らないことを意味します。
CVSでは、コミットしようとすると、複数のファイルでコミットが成功し、他のいくつかのファイルで失敗する可能性があります(変更されているため)。これにより、コミットの半分が存在しないため、リポジトリが不幸な状態になります。また、コンパイルまたは悪化しない状態のままにしておく可能性があります。これで、他の誰かが更新する必要があり、壊れた変更セットを取得する前に他のファイルをコミットできるように、急いですべての変更を統合する必要があります。
SVNではこれは起こりません。SVNは変更したすべてをコミットするか、変更セット全体を失敗させます。したがって、コミットの問題が原因でリポジトリが破損した状態のままになることはありません。
これは、たとえばBye-bye CVSで説明されています。私は Andy Lesterによって書かれた記事を覆されました:
Subversionでコミットしようとしても、ファイルの1つに競合があるか、最新ではない場合、どのファイルもコミットしません。CVSには、今すぐ修正しなければならない半分コミットされたファイルのセットがあります。
CVSがプログラマにマージをすぐに修正することを強制するという事実は、それが得るほど非生産的です。それと比較して、変更を遅延/キャンセル/慎重にマージするオプションは大きな利点です。
上記の記事で説明したCVSに対するSVNのその他の利点は次のとおりです。
行うすべてのローカルバージョン
cvs diffを使用する場合は、リポジトリに接続できる必要があります。ネット接続も差分もありません。Subversionは作業中のローカルコピーを保存するため、svn diffは問題なく動作します。やり直しますか?svn revertも接続されていません。リビジョン
HEADの記号名はCVSのトランクの先端の名前ですが、PVCSの時代に戻ったように、「-r-1」と常に言いたいと思っていました。CVSでは、編集しているものに対してcvsのログを作成し、1を差し引く必要があります。それは面白くない。Subversionでは、svn diff -r PREVと言えます。実際のステータスレポート
CVSでは、サーバー上の何かが新しいかどうかを確認できる唯一の方法は、cvs updateを実行し、ダウンしたものが競合を引き起こさないことを期待することです。svn statusコマンドを使用すると、実際のステータスが取得されるため、更新を行う前に競合があるかどうかを確認できます。マージの競合の
便利な処理CVSでは、競合がある場合、ファイルに競合マーカーが表示されます。Subversionでは、競合マーカーに加えて、元の競合前のファイルのコピー、サーバーからダウンしたバージョン、および元々編集していたバージョンを取得します。次に、filename.txtを明示的にsvn resolveして、問題を解決したことをSubversionに通知する必要があります。競合マーカーがまだある状態で、誤ってCVSにコミットすることはもうありません。