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)")
