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)
the descend can jump several directories down in one hit, eg: when a user
mentions multiple directories on the command line, eg: "cvs diff
sys/i386/isa/snd sys/sys". The problem is that the chdir()s are
pushed/popped to account for this, but the "full path" merely has
the last component chopped off on the way back up. This busts lots
of things when the recursion is backing up more than one directory (such
as in the example). This causes 'cvs diff' to emit bogus Index: lines,
'cvs update' to do really stupid things, 'cvs commit' to record incorrect
pathnames etc. I'm not sure that what I've done is quite correct, there
seems to be a comment that implies some sort of problem with "." vs. ""
equivalence or not, perhaps this is a problem on some other OS's, but
I've not (yet) found any problems. This bug has been present since
at least cvs-1.8.1.
This should fix problems noted by several people including asami and jmg.
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.
log messages after they've been entered. This is more flexible than
using the editinfo script since it works for all log message types
and doesn't have to deal with trying to run the editor for the user.
The problem is that the verifymsg script can't modify the file like
editinfo can, which makes it useless for cleaning up the message (as is
needed for remote commits etc). This change causes the verifymsg handler
to read back the message after the verify script has run and returned an
"OK" exit code.
few more memory leaks and cleaned up getopt usage. These were done shortly
after the last one I imported. Very little has changed other than that.
(except for some doc updates)
Obtained from: cyclic.com
When using a local repository that is only written to by CVSup - which
I assume doesn't do the cvs locking protocol - this option might be a
speedup since cvs will not create lock files.
such as within an anoncvs server, or from a CDROM repository.
Cyclic (the cvs maintainers) do not like this approach and have an
alternative read-only system, but that requires a read/write repository to
work (which rules out CDROM).
Obtained from: OpenBSD
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
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
I.e., "cvs -H init" went ahead and initialized the repository, and did
not print out a usage message. Not nice.
Also added the "init" command to the list that comes out when you type
"cvs --help-commands". There is still not a word about it in the manual
page.
Yes, I am sending these fixes to the FSF.
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)")
