ノード: Examining And Reverting Changes, 次: , 前: Finding Out Who Did What (Browsing Log Messages), 上: A Day With CVS



Examining And Reverting Changes

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つあります。ゆっくりチマチマ やる方法と、速くてカッコイイ方法です。まずはゆっくりチマチマやる方法を先 に見ましょう。