| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
affects speed of doing 'cvs diff' (in all modes) and 'cvs update' over the
network.
1: don't pause at all unless running in server protocol mode.
2: if running in server protocol mode, do a kludge that intercepts the
stdout and stderr write functions and diverts them to cvs_output() and
cvs_outerr(). Yes, this might be done with fwopen() etc, but that also
requires copying "FILE" structs since you can't freopen stdout etc and
specify functions at the same time.
This HACK will go away once the cvs folks have done their changes to the
library version of gnu diff to use the callbacks as mentioned in the
comments.
|
| |
|
|
| |
ago. The real fix is rather large.
|
| |
|
|
| |
anymore, don't do all the putenv's for it's benefit.
|
| |
|
|
| |
(If only all import/merges were this trivial :-)
|
| |\
| |
| |
| | |
which included commits to RCS files with non-trunk default branches.
|
| | |
| |
| |
| |
| | |
imported a few days ago. There is very little difference, except that
the remote protocol apparently supports wrappers and -k options better.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/
| |
| | |
which included commits to RCS files with non-trunk default branches.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
things fixed in here, including the '-ko' vs. -A problem with
remote cvs which caused all files with -ko to be resent each time
(which is damn painful over a modem, I can tell you). It also found a
heap of stray empty directories that should have been pruned with the -P
flag to cvs update but were not for some reason.
It also has the fully integrated rcs and diff, so no more fork/exec
overheads for rcs,ci,patch,diff,etc. This means that it parses the control
data in the rcs files only once rather than twice or more.
If the 'cvs diff' vs. Index thing is going to be fixed for future patch
compatability, this is the place to do it.
|
| | |
| |
| |
| | |
precedence
|
| | |
| |
| |
| | |
CVS gurus from info-cvs agrees that previous Index: usage is bogus
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| | |
from XFree86. I think this was harmless, the strncmp happened always
rather than being optimised out.
Submitted by: jdp
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
over the code too and it makes sense to me.
PR: 4033
|
| | | |
|
| | | |
|
| |\ \
| |/
| |
| | |
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.
|
