.H2 "Problems with CVS"
.X "problems with CVS"
.X "CVS, problems with"
Occasionally, you'll run into problems updating your source tree.  Here are some
possibilities:
.H3 "Can't find directory"
Occasionally \fIcvs\fP\| will crash during an update with a message like:
.Dx
cvs update: Updating games/sail
U games/sail/externs.h
cvs update: Updating games/snake
cvs update: Updating games/snake/snake
U games/snake/snake/snake.c
cvs update: Updating games/snake/snscore
cvs update: Updating games/tetris
cvs [update aborted]: cannot open directory /src/cvs/src/games/tetris: No such file or
 directory
.De
.sp -1v
.Aside
This particular incident occurred after the owner of the name \fITetris\fP\|
required FreeBSD to remove the game then called \fItetris\fP\| from the sources.
.End-aside
The problem here is that the file \fI/usr/src/games/CVS/Entries\fP\| still
contained a reference to the directory, so \fIcvs\fP\| failed.  One way to fix
this problem is to manually edit the file \fICVS/Entries\fP, but it's easier to
remove the \fICVS\fP\| directory and start again:
.Dx
# \f(CBcd /usr/src/games\fP
# \f(CBrm -rf CVS\fP							\fIremove the CVS information\fP\|
# \f(CBcd ..\fP								\fIgo to the parent directory\fP\|
# \f(CBcvs co games 2>&1 | tee /var/tmp/co.log\fP\fP		\fIand check the games directory out again\fP\|
.De


.H3 "CVS doesn't update files"
Rename CVS dir, try co again

===> usr.sbin/sendmail/src
"Makefile", line 24: Need an operator
"Makefile", line 26: Need an operator
"Makefile", line 32: Need an operator
make: fatal errors encountered -- cannot continue
*** Error code 1

Stop.
*** Error code 1

Stop.


<<<<<<< Makefile
CFLAGS+=-I${.CURDIR} ${DBMDEF} ${NIS} -DNAMED_BIND=1 #-DNETISO
=======
# If you want tcp wrapper support, uncomment the following two lines
#TCPWRAPPERSBASEDIR=	/usr/local
#TCPWRAPPERS=		-DTCPWRAPPERS -I${TCPWRAPPERSBASEDIR}/include

CFLAGS+=-I${.CURDIR} ${DBMDEF} ${NIS} ${TCPWRAPPERS} #-DNETISO
>>>>>>> 1.13

SRCS=	alias.c arpadate.c clock.c collect.c conf.c convtime.c daemon.c \
	deliver.c domain.c envelope.c err.c headers.c macro.c main.c map.c \
	mci.c mime.c parseaddr.c queue.c readcf.c recipient.c safefile.c \
	savemail.c srvrsmtp.c stab.c stats.c sysexits.c trace.c udb.c \
	usersmtp.c util.c version.c

C Makefile

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Date: Fri, 3 Oct 1997 09:49:22 -0500
From: Karl Denninger  <karl@Mcs.Net>
To: Mike Smith <mike@smith.net.au>
Cc: Invis <invis@visi.com>, freebsd-current@FreeBSD.ORG
Subject: Re: How much work does running -current take?
X-Mailer: Mutt 0.64

On Fri, Oct 03, 1997 at 11:40:48PM +0930, Mike Smith wrote:
> > 
> > 1. If I install -current, will I have to do 'make worlds' or other 6 hour CPU
> >        tasks often?
> 
> You won't have to.  You may want to.
> 
> > 2. Will my system more often than not be able to boot and run most of the time?
> >    i.e. I have one computer, I don't mind constant reboots, even making my own
> >    code patches if necessary, but if this is something it's almost necessary
> >    to have two machines for, please tell me!
> 
> It can be helpful to have two systems, but things are generally better 
> now than they were in terms of re-bootstrapping yourself.
> 
> >     3. Where can I get a list of new features available in 3.0-current ??
> 
> The CVS commitlogs are the most verbose resource.
> 
> mike

There are times when -current is EXTREMELY unstable.

My hints and tricks include:

1)      If you have two machines, its a REALLY good idea to keep one of
        them in usable condition at all times until you've completed testing
        on new stuff.

2)      Any time the kernel changes drastically enough that libkvm and
        friends (ie: ps, etc) needs to be rebuilt you can get screwed.  Use
        extra caution at those times.  Those are the times when its most
        dangerous, because you might not be easily able to back out a bad
        change.

3)      Learn how to check out and/or update your local copy with the "-D"
        switch to cvs (ie: cvs update -D "yesterday" .).  This can save your
        bacon if you ARE rebuilding all the time and one day it breaks when
        you knew it was ok yesterday.

4)      If you are making local changes to the sources (we do here) be
        extremely cautious in exactly how you go about things.  You must
        learn how CVS actually does stuff so you don't accidentially lose
        your local changes.  ALWAYS, ALWAYS keep a local context diff of
        your changes against a known base version SOMEWHERE ELSE.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Date: Mon, 6 Oct 1997 20:38:52 -0400 (EDT)
From: jack <jack@diamond.xtalwind.net>
To: Richard Wackerbarth <rkw@dataplex.net>
cc: hackers@FreeBSD.ORG
Subject: Re: Help finding CVSup 15.2

On Mon, 6 Oct 1997, Richard Wackerbarth wrote:

> At John's request, I upgraded to the latest CVSup.
> (He's OOT. Otherwise I would have just asked him to help solve this)
> 
> Unfortunately, the package needs some "X" libraries. I don't have them on
> my servers.
> 
> Can someone point me to a version of CVSup 15.2 that is linked without
> using the graphical libraries?

     * ftp://hub.freebsd.org/pub/CVSup/cvsup.nogui-bin-15.2.tar.gz
       (client without GUI).

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

From: Kenneth Merry <ken@plutotech.com>
Subject: Re: Current 3.0 10-9-97i
To: rbolin@netchannel.net (Ron Bolin)
Date: Fri, 10 Oct 1997 10:03:32 -0600 (MDT)
Cc: freebsd-current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL28s (25)]

Ron Bolin wrote...
> In building the present current, the ps command gives the following
> error:
> 
> rlb3:/home/rbolin>ps -a
> ps: proc size mismatch (1312 total, 652 chunks)
> 
> I believe this is connected with a change in the proc file system as the
> man pages shows several different
> directories under /proc that I don't have. Where is the best place to
> determine what to do when changes are made in
> current like this - or is browsing the source the only place or am
> I just in the middle of some in progress work?

        The best way to find out when changes like this are made is to read
the -current mailing list, and the cvs-all list.

        Whenever you get errors like that from ps, or w (I'd bet that w
will give you bogus results as well), the best thing to do is:

rebuild and reinstall libkvm
then, rebuild ps, w, and top

        I just updated the kernel on one of my machines last night, and I
got a similar error message.  Rebuilding things in that order fixed them
for me.  (and that will almost always fix problems like that)

(BTW, you might want to adjust your mailer so that it doesn't send both
text and html versions of your mail...)

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Check the cvs update stuff for C conflicts

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


From: Greg Lehey <grog@lemis.com>
To: David Kelly <dkelly@nebula.tbe.com>
Cc: FreeBSD Hackers <hackers@freebsd.org>
Bcc:
Subject: Re: How to get an older if_de.c?
Reply-To:
In-Reply-To: <199801202309.RAA10002@PeeCee.tbe.com>; from David Kelly on Tue, Jan 20, 1998 at 05:09:40PM -0600
Organization:   LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone:          +61-8-8388-8286
Fax:            +61-8-8388-8725
Mobile:         +61-41-739-7062
WWW-Home-Page:  http://www.lemis.com/~grog

You sent this message to -hardware, which doesn't seem appropriate.
I'm following up to -hackers.

On Tue, Jan 20, 1998 at 05:09:40PM -0600, David Kelly wrote:
> I'm guessing the solution to my de0 problem is an older version of
> if_de.c ???
>
> dmesg says:
> de0 <Digital 21040 Ethernet> rev 35 int a irq 11 on pci0:14
> de0: not configured; 21040 pass 2.0 required (0.0 found)
>
> or maybe there is a way to hack my early December version
> into compliance? In the mean time an old NE2000 clone has
> been pressed into service.
>
> I have the CVS directory tree, updated via CTM as of this
> morning. If some one could get me started on how to use CVS
> to trace the history of if_de.c and extract a selected version
> then I'd be happy. Would also like to know how to protect that
> copy against further upgrades on my machine.

OK.

1.  To get the revision history, use cvs log:

> $ cvs log if_de.c
> RCS file: /src/cvs/src/sys/pci/if_de.c,v
> Working file: if_de.c
> head: 1.77
> branch:
> locks: strict
> access list:
> symbolic names:

These are mappings between names and RCS version numbers.  You won't
see the names again in the list of changes, which list only the
version numbers.  Refer back here to tranform the version number to a
version name.

>         v971020: 1.1.1.5
>         RELENG_2_2_5_RELEASE: 1.54.2.9
>         v971017: 1.1.1.4
>         NETBSD: 1.1.1
>         v970703: 1.1.1.3
>         WOLLMAN_MBUF: 1.65.0.2
>         BP_WOLLMAN_MBUF: 1.65
>         v970513: 1.1.1.2
>         v970508: 1.1.1.1
>         MATT_THOMAS: 1.1.1
>         RELENG_2_2_2_RELEASE: 1.54.2.5
>         post_smp_merge: 1.64
>         pre_smp_merge: 1.64
>         RELENG_2_2_1_RELEASE: 1.54.2.3
>         RELENG_2_2_0_RELEASE: 1.54.2.3
>         RELENG_2_1_7_RELEASE: 1.29.2.8
>         RELENG_2_1_6_1_RELEASE: 1.29.2.7
>         RELENG_2_1_6_RELEASE: 1.29.2.7
>         RELENG_2_2: 1.54.0.2
>         RELENG_2_2_BP: 1.54
>         RELENG_2_1_5_RELEASE: 1.29.2.5
>         wollman_polling: 1.44.0.2
>         RELENG_2_1_0_RELEASE: 1.29.2.5
>         RELENG_2_1_0: 1.29.0.2
>         RELENG_2_1_0_BP: 1.29
>         RELENG_2_0_5_RELEASE: 1.28.2.1
>         RELENG_2_0_5: 1.28.0.2
>         RELENG_2_0_5_BP: 1.28
>         RELENG_2_0_5_ALPHA: 1.27
>         OLAH_TTCP: 1.7.0.2
>         RELEASE_2_0: 1.7
>         BETA_2_0: 1.6
>         ALPHA_2_0: 1.4
>         V941001: 1.1
> keyword substitution: kv
> total revisions: 102;   selected revisions: 102

The following are the change strings for each version.

> description:
> ----------------------------
> revision 1.77
> date: 1998/01/08 23:42:24;  author: eivind;  state: Exp;  lines: +5 -2
> Make INET a proper option.
>
> This will not make any of object files that LINT create change; there
> might be differences with INET disabled, but hardly anything compiled
> before without INET anyway.  Now the 'obvious' things will give a
> proper error if compiled without inet - ipx_ip, ipfw, tcp_debug.  The
> only thing that _should_ work (but can't be made to compile reasonably
> easily) is sppp :-(
>
> This commit move struct arpcom from <netinet/if_ether.h> to
> <net/if_arp.h>.
> ----------------------------
> revision 1.76
> date: 1997/12/15 20:31:25;  author: eivind;  state: Exp;  lines: +3 -1
> Throw options IPX, IPXIP and IPTUNNEL into opt_ipx.h.
>
> The #ifdef IPXIP in netipx/ipx_if.h is OK (used from ipx_usrreq.c and
> ifconfig.c only).
>
> I also fixed a typo IPXTUNNEL -> IPTUNNEL (and #ifdef'ed out the code
> inside, as it never could have compiled - doh.)

2.  To check out a version, you can use either a date spec, a version
    name, or a version number.  For example, you may determine that
    you want the version before the SMP merge (label pre_smp_merge:
    1.64).  Here's the checkin information (from cvs log):

      revision 1.64
      date: 1997/04/05 07:59:41;  author: phk;  state: Exp;  lines: +2 -2
      Recognize ZNYX 314 cards that have a MAC address with the low bit set.

   You can use one of the following methods to check out this version:

   a.  By date:

       cvs update -D "5 April 1997 07:59:41 UTC" if_de.c

   Note that RCS (and thus cvs) keeps its dates in UTC, so it's best
   to specify your dates in UTC.  You can specify them locally, but
   you then need to convert the time correctly.  RCS looks for the
   latest version which existed at the time you specified: if you
   specify "5 April 1997 07:59 UTC", you will get an older version,
   but if you specify "5 April 1997 08:00 UTC" you'll get the one you
   want.

   b.  By revision number:

       cvs update -r1.64 if_de.c

   c.  By revision tag:

       cvs update -r pre_smp_merge if_de.c

A word of caution: all these methods are "sticky".  Any further update
will give you the same version until you tell cvs something else.  For
example, when you're ready for the latest and greatest version again,
you can write:

       cvs update -A if_de.c

cvs keeps information on the current version in the file CVS/Entries.
To see which version you currently have, enter:

$ grep if_de.c CVS/Entries
/if_de.c/1.64/Wed Jan 21 05:48:58 1998//D97.04.05.08.00.00

Let me know if you need any more information; I'll add this to the
next edition of "The Complete FreeBSD".

Greg

--------------------------------------------------

To remove patched  files,

grep "RCS file" diffs | sed 's:.*freebsd/:/usr/:; s:,v$::'|xargs rm
