How to actually perform a CVS pull-up

For a given release cycle, typically in the beginning, developers may be expected to do pull-ups themselves after approval from the release engineering team.

Let us say you are pulling up the changes between foo.c 1.19 and 1.21.

First, and foremost, make sure you are starting with a clean foo.c

  cvs update -rnetbsd-1-4 foo.c
  

(See note at the end about the effect of this command.)

Then, you need to patch up foo.c to add the changes you want to pull up. There are two ways of doing this. You can create a patch file and apply it, or you can use cvs update's -j flag to avoid needing that.

The incantation:

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

will produce a patch file which you can then apply by doing

  patch </tmp/patch
  

or by feeding it directly to patch via a pipe. The command

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

is essentially equivalent to the two steps listed above, and will similarly patch your file.

Now manually examine the file to make sure What You Wanted Done Is Done. If you are trying to make foo.c identical to the head (presumably 1.21 is the head and 1.19 was the branch point or some such), you can do a

  cvs diff -kk -r1.21 foo.c
  

and this should produce no diff (-kk prevents the expansion of RCS IDs). If foo.c isn't supposed to be identical to the head, you are going to have to make sure things are okay manually or use creative sets of cvs diffs to assure that what you wanted done was done.

In any case, once done, do a:

  cvs commit foo.c
  

The format of the commit message on a release branch has over time been formalized to ease tracking and maintenance. The format of the first line of the commit message should be one of the following:

or obvious minor variations over these themes. The rest of the commit message shall contain a free-format text explaining why the pull-up was done. This message should preferably be an "externally sensible" message explaining what was fixed, not the exact details of how it was done. The text of this message should be indented by two spaces, and for patch releases this text should also go in as an entry in the appropriate CHANGES file.

If the pull-up fixes a formally reported problem, this should be noted as Fixes PR#nnnn at the end of the commit message text.

The fact that we want exact revision numbers recorded in the commit message means, BTW, that you must not do a bunch of pull-ups in the same directory and then commit them with a message like "sync with trunk," because that won't say what versions you pulled up.

  cvs update -rnetbsd-1-4 foo.c
  

  cvs update -A foo.c