| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| |
| | |
which included commits to RCS files with non-trunk default branches.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| |\ \
| |/
| |
| | |
which included commits to RCS files with non-trunk default branches.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| | |
complaining about long-deleted files having been deleted and that there
is no diff available.
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| | |
than depending on getting a write fail.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| |\ \
| |/
| |
| | |
which included commits to RCS files with non-trunk default branches.
|
| | |
| |
| |
| | |
Obtained from: cyclic.com
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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)")
|
|
|
and non-unix code has been left out.
|
