On 2007-01-14 15:35, Bill Moran <[EMAIL PROTECTED]> wrote:
> Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> [copious snippage]
> > > 2. Cd /usr/src/sys/amd64/conf which contains the file MYKERNEL
> >
> > No it doesn't.  CVSup will delete the files it doesn't know about, so
> > you should *SAVE a copy* of your favorite kernel config file outside of
> > the source tree and *copy* it into `/usr/src/sys/amd64/conf' after CVSup
> > finishes updates the sources.
> Really?  What have I been doing wrong?  I've been keeping custom kernel
> configs for years and cvsup has never deleted any of them.

That's what the ``*default delete use-rel-suffix'' option does, AFAIK.

The default supfile examples in `/usr/share/examples/cvsup' have this
option enabled, and cvsup(1) says about it:

  delete  The presence of this keyword gives cvsup permission to
          delete files.  If it is missing, no files will be deleted.

          The presence of the delete keyword puts cvsup into
          so-called exact mode.  In exact mode, CVSup does its
          best to make the client's files correspond to those on
          the server.  This includes deleting individual deltas
          and symbolic tags from RCS files, as well as deleting
          entire files.  In exact mode, CVSup verifies every
          edited file with a checksum, to ensure that the edits
          have produced a file identical to the master copy on
          the server.  If the checksum test fails for a file,
          then CVSup falls back upon transferring the entire

          In general, CVSup deletes only files which are known to
          the server.  Extra files present in the client's tree
          are left alone, even in exact mode.  More precisely,
          CVSup is willing to delete two classes of files:
          o   Files that were previously created or updated by CVSup
          o   Checked-out versions of files which are marked as dead on
              the server.

If the option doesn't work this way, then I stand corrected.

>>> 4.Copy everything under /etc to /root/etc
>> Why?  This isn't mentioned in `/usr/src/UPDATING' and it doesn't really
>> help much if you manage to trash your /lib and /usr/lib trees.  A better
>> suggestion is to ``make sure you have good level 0 dumps'', as suggested
>> by ``/usr/src/UPDATING''.
> While not mentioned in /usr/src/UPDATING, this is good practice in my
> opinion.  mergemaster can be a tedious task, and making a local backup
> of /etc has allowed me to undo some careless keystrokes a number of times.
> I don't disagree with the dump advice, but an additional copy of /etc
> around doesn't hurt anything and occasionally makes fixing a mistake
> much faster an easier.

Heh, true :)

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to