|
|
NetBSD Developer Documentation:CVS - Misc developer notes |
Makefile 1.9 cat.1 1.16 cat.c 1.21
Makefile 1.8 cat.1 1.16 cat.c 1.19
Makefile 1.8 cat.1 1.16 cat.c 1.19.2.1
In all cases, when you then say "cvs update -r HEAD" you get the same as "cvs update -A" or "cvs update -Dnow".
When you do "cvs diff -r HEAD", however:
file: 1st -r: 2nd -r: ----- ------- ------- Makefile 1.9 1.9 cat.1 1.16 1.16 cat.c 1.21 1.21(i.e. no output.)
Makefile 1.9 1.8 cat.1 1.16 1.16 cat.c 1.21 1.19(yes, those are backwards, since "cvs diff -r foo" uses as the 'first' set of files those with rev. foo, and the second those that you've got already checked out.)
Makefile 1.9 1.8 cat.1 1.16 1.16 cat.c 1.19.2.1 1.19.2.1
In other words, "cvs update -r HEAD" is equivalent to "cvs update -A" or "cvs update -Dnow" (at least in the simple cases where there's no date-based attic lossage).
However, "cvs diff -r HEAD" compares each file with the head of its branch. For some files on a branch (those which have been branched but for which there are no changes on the actual branch), the diff will be against the head of the branch that they were branched from (e.g. in the cat/Makefile case above, the head of the trunk). For others (those which do have changes on the branch), the diff will be against the head of the currently-checked out branch.
In other words, you can't reliably use diff against -r HEAD to test whether a file matches the head of the trunk.
You can use -Dnow (but that's occasionally kinda broken, in the presence of deleted files... though at least not too verbose about it
After a commit to the branch, if you're willing to do multiple updates and use -kk, you can also tell by doing something like:
and if there are no files modified/added/deleted, the two are in sync.
So, in a nutshell, HEAD's pretty evil, i'd suggest avoiding it. (cgd)
.cvsignore files are not to be used in most parts of the NetBSD source code repository. (That is, after discussion, they have been banned from the source tree.) All modules other than pkgsrc are currently included in this prohibition.
.cvsignore files have been banned because, in a nutshell, they cause problems for NetBSD development. There are two main classes of problems which they encourage: incomplete cleaning, and bogus files left in distributions.
Regarding the problem of incomplete cleaning, NetBSD sources should build and clean leaving only the original sources. If other files, e.g. object files or other files created as a by-product of building, are left around after a complete clean with make cleandir, that is a bug. .cvsignore files are used to mask that bug, and therefore should be avoided.
Regarding the problem of building a distribution that does not include bogus files, the easiest way to verify that there are no bogus files in the distribution is to run "cvs update" with the flags "-I! -ICVS". However, .cvsignore entries are added to CVS's list of files to ignore after the -I flags are processed, and so it is impossible to cause CVS to ignore files mentioned in .cvsignore files! The possible consequences of this should be obvious: files can accidentally creep into source snapshots because they were mentioned in .cvsignore files and, for whatever reason, were not properly removed.
When importing packages which include .cvsignore files, make CVS ignore them by specifying the "-I .cvsignore" option to the "cvs import" command.
Some time ago there were some scripts that moved the actual RCS files around -- this is not supported anymore, just remove the file and add it in the new place, noting where it was moved from or to respectively, to make tracking these moves easier in years to come. For more files at once, you can also cvs import them instead of cvs adding them.
|
|
Home Page