Node: Examining And Reverting Changes, Next: The Slow Method Of Reverting, Previous: Finding Out Who Did What (Browsing Log Messages), Up: A Day With CVS
qsmith がログを読んでいて、jrandom が hello.c に最近ほどこした変更を見た とします:
revision 1.4 date: 1999/04/20 04:14:37; author: jrandom; state: Exp; lines: +1 -1 adjusted middle line
彼は「jrandom は一体何をしとんねん」と思いました。qsmith がたずねた質問 を正確な言葉で言うと、「hello.c のわたしのリビジョン(1.3)と、そのすぐあ との jrandom のリビジョン(1.4)の違いは何なのでしょう」ですね。これは diff コマンドでわかることですが、今回は過去の2つのリビジョンを比べるので、 -r コマンドオプションを使ってそれらを指定します:
paste$ cvs diff -c -r 1.3 -r 1.4 hello.c Index: hello.c =========================================================== RCS file: /usr/local/cvs/myproj/hello.c,v retrieving revision 1.3 retrieving revision 1.4 diff -c -r1.3 -r1.4 *** hello.c 1999/04/20 02:30:05 1.3 --- hello.c 1999/04/20 04:14:37 1.4 *************** *** 4,9 **** main () { printf ("Hello, world!\n"); ! printf ("between hello and goodbye\n"); printf ("Goodbye, world!\n"); } --- 4,9 -- main () { printf ("Hello, world!\n"); ! printf ("BETWEEN HELLO AND GOODBYE.\n"); printf ("Goodbye, world!\n"); } paste$
このように見ると変更点は明らかです。リビジョン番号を時系列順に指定したの で(普通はこれでいいです)、diff もその順で示されます。リビジョン番号を1つ だけ指定すると、CVS は現在の作業コピーを比較対象にします。
qsmith はこの変更を見てすぐ、自分のやりかたの方がいいから、「アンドゥー」 つまりリビジョンをひとつ戻して解決するんだ、と決めました。
しかし、彼はリビジョン1.4を捨てたいというわけではありません。ですが、た だ技術的な問題としてどうかというと、CVS ではそういうことも可能です、たい がいそんなことをする理由はないですが。リビジョン1.4をそのままにしておい て、1.3 にそっくりな新しいリビジョン1.5を作るほうがましです。こうすると、 アンドゥーそのものもそのファイルの履歴に残ります。
残るはどうやってリビジョン1.3を取ってきてそれを1.5とするか、という疑問だ けです。
この場合に限って言うと、とてもシンプルな変更なので qsmith が 1.3 をうつ すよう手でファイルを編集して、それをコミットすれば済みます。でも、変更が もっと複雑になったら(実際のプロジェクトでは普通そうでしょう)、古いリビジョ ンを手でもう一回作るというのはどう考えても間違えそうです。ですから、 qsmith は CVS を使って古いリビジョンを取ってきて、それを再コミットするべ きです。
これを実現するために、同じくらい良い方法が2つあります。ゆっくりチマチマ やる方法と、速くてカッコイイ方法です。まずはゆっくりチマチマやる方法を先 に見ましょう。