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.

(Nota bene: the idea of "pulling up to 1.21" is meaningless -- you are always applying diffs between two versions. One of them might be the base tag, but in any case, since you are pulling up diffs, you always need to know the two versions between which the changes occurred.)

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:

Pull up revision 1.45 (requested by user):
Pull up revision 1.45 (via patch, requested by user):
Pull up revisions 1.1-1.5 (new, requested by user):
Apply patch (requested by user):

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.

Note that the command

cvs update -rnetbsd-1-4 foo.c

will glue foo.c to "netbsd-1-4" (see what happens to CVS/Entries), and subsequent CVS commands will thus apply to this release until you unstick this "glue" with

cvs update -A foo.c

Home Page

Developer Documentation