rev 1.27 ("iso8601" option keyword) revs 1.12/1.10/1.5/1.4 ($CVSHeader$
support) rev 1.2 ($CVS_LOCAL_BRANCH_NUM support for local commit
feature of cvsup) into version 1.11-20080310.
rev 1.27 ("iso8601" option keyword) revs 1.12/1.10/1.5/1.4 ($CVSHeader$
support) rev 1.2 ($CVS_LOCAL_BRANCH_NUM support for local commit
feature of cvsup) into version 1.11.22.
Note rev 1.21 ("-D date" checkout bug relating to 1.1.1.1 vs 1.1
revisions), rev 1.13 (allow -D'date' with -r'branch' on a checkout),
rev 1.6 (use xstrdup rather than strdup) are fixed in the vendor sources
pointer dereferences, possible use of uninitialized variables, and
memory leaks.
Security: CAN-2005-0753
Security: FreeBSD-SA-05:05.cvs
Approved by: peter
"-D date" command line option. There is code in the original to
handle a special case. If the date search finds revision 1.1 it
is supposed to check whether revision 1.1.1.1 has the same date
stamp, which would indicate that the file was originally brought
in with "cvs import". In that case it is supposed to return the
vendor branch version 1.1.1.1.
However, there is a bug in the code. It actually compares the date
of revision 1.1 for equality with the date given on the command
line -- clearly wrong. This commit fixes the coding bug.
There is an additional bug which is _not_ fixed in this commit.
The date comparison should not be a strict equality test. It should
allow a fudge factor of, say, 2-3 seconds. Old versions of CVS
created the two revisions with two separate invocations of the RCS
"ci" command. We have many old files in the tree in which the
dates of revisions 1.1 and 1.1.1.1 differ by 1 second.
Approved by: peter
1998-03-07 Tim Pierce <twp@skepsis.com>
* rcs.c (RCS_checkout): Negation bug when checking out symlinks:
existence_error should be !existence_error.
This shouldn't cause any major merge problems later.
on a checkout.
this allows us to do:
cd /usr/src/sys
cvs update -rRELENGE_2_2 -D"Yesterday"
which has been a feature sorely needed for any project with active branches.
warning: this breaks on usr.sbin/pkg_install for some reason.
everything else works as advertised.
(other things allready break on pkg_install, so it's not the fault of
this patch, it just falls faul of another bug somewhere)
If I had more time I'd make -r always accept the same syntax as -j (tag:data)
but adapted to run within cvs instead of rcs.
The stuff I hacked together didn't strip out "/Attic/" for files
on branches when the HEAD version was cvs rm'ed.
controls the RCSINCEXC encironment variable for our rcs version, and
also convert the rest of the checkout enhancements from rcs into cvs's
fast checkout code. (yes, cvs doesn't call 'co' anymore)
We now have fine grained individual keyword expansion control and can
set the keyword to anything the user wants.
Also, a new keyword, $CVSHeader$ comes in from rcs, it's like $Header$
except that it shows the pathname relative to the cvsroot. eg:
$FreeBSD: src/bin/ls/ls.c,v 1.10.2.14 1997/05/17 13:15:45 peter Exp $
^^^^^^^^^^^^^^^^^
The idea for this comes from $XFree86$ which expands like $CVSHeader$.
The "local id" string can be set to expand like Id, Header or CVSHeader.
(Matching support for this is apparently happening in cvsup right now)
This is not complete yet in that it doesn't drive our version of RCS
completely, but it does work fine when you do the appropriate magic.
Obtained from: OpenBSD source tree
branch number that is assigned. This is specifically to support the
local commit feature of cvsup. If one sets $CVS_LOCAL_BRANCH_NUM to
(say) 1000 then branches the local repository, the revision numbers will
look like 1.66.1000.xx. This is almost a dead-set certainty that there
will be no conflicts with version numbers. :-)
(This needs to be something more than an option to 'cvs tag' or 'cvs rtag'
as various parts of cvs "know" how to automatically branch files (eg: cvs
add). Trying to remember state is getting "Too Hard (TM)")
