CVS pullup を実際に行う方法

リリースサイクルの期間中、普通はその初期段階に、開発者は リリースエンジニアの承認を受け、 その後に自分で pullup を行うようになっています。

foo.c 1.19から1.21 への変更を pullup する場合を例にしてみましょう。

まず初めに、完全な foo.cから始めることを確認します。

  cvs update -rnetbsd-1-4 foo.c
  

(このコマンドの効果については、最後にある注意を参照してください。)

そして、 pullup したい変更を加えるため、foo.cにパッチを当てる必要があります。 これには二つ方法があります。 パッチファイルを作成してあてるか、それを避けるためにcvsコマンドのupdateにある -j フラグを使う事ができます。

まじない:

   cvs diff -kk -c -r1.19 -r1.21 foo.c >/tmp/patch
  

で、以下のコマンドであてることができるパッチファイルを作成できます。

  patch </tmp/patch
  

こうするかわりに、パイプを介してパッチを直接あてることもできます。コマンド

  cvs update -kk -j1.19 -j1.21 foo.c
  

は、基本的に上にかいてある二つの段階と同等で、 同じようにファイルにパッチをあてます。

さあ、あなたが望んだ結果になっているか確認するため、 ファイルを手動で調べてみましょう。 foo.cが穂先と一致しているか調べたいならば (多分1.21が穂先で、1.19が枝の分岐点か似たようなものでしょう) 、 こうします

  cvs diff -kk -r1.21 foo.c
  

すると、差分はまったくないはずです (-kk は RCS ID の展開を抑止します)。 もしfoo.cが穂先と一致していないと思われるならば、 手動で大丈夫であることを調べるか、望んだ通りになることを確かめるため cvsの創造的なセットを使用するかしなければいけません。

とにかく、一度diffがあてられたら、こうします:

  cvs commit foo.c
  

リリース枝のコミットメッセージの形式は、これまでの歴史のなかで、 追跡や保守を容易にするために標準化されてきました。 コミットメッセージの一行目は、以下の形式のいずれか、または明らかで軽微な亜種でなければなりません。

コミットメッセージの二行目以降には、 pullup をした理由の説明を、 自由な形式で記してかまいません。このメッセージでは、なるべく、 修正方法の詳細を厳密に書くのではなく、何を修正したのかを "対外的にわかるように" 説明するようにしてください。 この説明は、スペース 2 個で字下げするようにし、 また、パッチリリースに対しては、適切な CHANGES ファイルにこの説明の項目を加えてください。

この pullup によって、公式に報告されている問題が修正された場合は、 コミットメッセージの説明の最後に Fixes PR#nnnn のように記してください。

さて、コミットメッセージにリビジョン番号を正確に記録するよう求めましたが、 これは、同じディレクトリーに対する pullup をまとめてコミットして、"sync with trunk," ですませたりしてはいけないということです。これでは どのバージョンを pullup したかがわからないからです。

  cvs update -rnetbsd-1-4 foo.c
  

  cvs update -A foo.c