Node: My commits seem to happen in pieces instead of atomically, Next: , Previous: The pserver access method is STILL not working, Up: Some Real Life Problems (With Solutions)



My commits seem to happen in pieces instead of atomically

コミットがアトミックにではなく、バラバラにおこなわれるようです

それは CVS がコミットをアトミックにでなく、バラバラにおこなっている からです。:-)

もっと言うと、CVS のオペレーションはディレクトリごとにおこなわれます。 複数のディレクトリにわたるコミットを実行したとき(あるいはアップデー トやなんか(or an update, or anything else, for that matter))、CVS は 順々に各リポジトリディレクトリ中でオペレーションを実行する間、そのディ レクトリにロックをかけます。

小〜中サイズのプロジェクトでは、これが問題になることはめったにありま せん。CVS は各ディレクトリ中での処理を素早くおこなうので、ユーザはそ の非アトミック性に気づいたりはしないでしょう。しかしあいにく大きなプ ロジェクトでは次の筋書きのようなきおとが起こり得ます(これが深くてファ イルのたくさんあるサブディレクトリを少なくとも2つ(A と B)持つプロジェ クトで起こる、と想像してください):

  1. ユーザ qsmith がコミットを始めます。そのコミットには両方のサブディレ クトリ中のファイルを含んでいます。CVS はまず B のなかのファイルをコ ミットします(おそらく qsmith はコマンドライン中でその順にディレクト リを指定したのでしょう)
  2. ユーザ jrandom がアップデートを始めます。アップデートは何らかの理由 で作業コピーのディレクトリAから始まりました(CVS はディレクトリやファ イルをどの順で処理するかについては何の保証もしません、if left to its own devices)。qsmith はまだ A では作業していませんので、ロックは問題 ではないことに注意してください。
  3. そして qsmith が B のコミットを終え、A に移り、A を終えます。
  4. 最後に jrandom が B に移り、アップデートを終えます。

全部終わった時点で、jrandom の作業コピーには qsmith の B の変更は反 映されている一方 A の変更が反映されていないことは明らかです。qsmith がそれらの変更をひとつの単位としてコミットしたつもりだったとしても、 実際はそのようにはなりませんでした。jrandom の作業コピーは qsmithが 予想もしない状態になってしまっています。

もちろん、jrandom がもう一度 cvs update して、さっき取って来れなかっ た qsmith のコミット分の変更を取って来れば、問題は解決します。しかし それは、最初に qsmith の変更のうち一部分しか取って来なかったことを知 るすべがあれば、の話です。

この quandary に容易な答はありません。ただ、作業コピーが一貫性のない 状態になっていることがどうにかして明らかになることを祈るほかありませ ん(そのソフトウェアがビルドできないかもしれませんし、何が起こったの かを認識するまで jrandom と qsmith が混乱した会話をすることになるか もしれません)。

一般に、CVS がアトミックなトランザクションを保証できていない についてはバグだと考えられています。ロックがリポジトリのトップレベル に作られないただひとつの理由というのは、開発者が大勢いる大きなプロジェ クトではロックの競合が耐えられないくらい頻繁に起こるであろうというこ とです。従って、CVS は2つの害のうち小さなほうを選びました。競合の頻 度を減らすかわりに、とびとびに読んだり書いたりする可能性を許した、と いうことです。そのうち誰かが CVS を改良し(たとえばリポジトリオペレー ションの速度を上げるなどして)、2つの害のどちらけを選んだりしなくても よくなるかもしれません。それまでは、ノンアトミックな動作に甘んじるこ とになるでしょう。

より詳しいことを知るためには、 Cederqvist マニュアルの Concurrency を参照してください。