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
1.19 and 1.21.
NoteThe 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
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
cvs diff -kk -c -r1.19 -r1.21 foo.c >/tmp/patch
will produce a patch file which you can then apply by doing
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
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
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
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.cwill glue
foo.cto "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