Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Dec 2004 22:28:08 -0500 (EST)
From:      Tom Huppi <>
Subject:   notes and/or RCS (was:Re: Root directory filling up...
Message-ID:  <>
In-Reply-To: <>
References:  <000101c4e215$2cdfedc0$9900000a@ZGISH> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

On Tue, 14 Dec 2004, Nikolas Britton wrote:

> Kiffin Gish wrote:
> >Wow, that seems like a lot of work. Suppose instead I choose just to
> >reinstall everything all over again...


> save a copy of the dmesg output... "dmesg >> /home/dmesg"
> basically save anything that you have made or edited
> I highly recommend starting a log/notes/diary for all this stuff;
> special settings, hard to remember commands, tips/tricks,
> special/complex procedures, advice etc.


One might also consider using RCS for most config file edits. I,
like many folks, started out using a series of notes.  After a
time I learned some simple RCS based tricks and now tend to use
them (actually, I do it habitually and religiously.)  The thing
that is really nice is a single command line that shows all the
files edited, what, when, where, and why (depending on input.) I
wish I had started doing this earlier in my unix work, and
probably would have had I run across these instructions:


More Detailed (what I used):
FreeBSD has RCS in the base system, so forget the 'installing
RCS' part.

Advantages (for a newbie, accd to me):

 - becomes pretty mechanical
 - teaches basics of RCS which helps understand CVS better.
 - some of the 'tricks' help understand more general unix tricks.
 - teaches about various gotchas (see below):

Gotchas (that I've run into):

 - some files are automatically edited like:
   - /etc/groups       (when installing certain ports)
   - /etc/reslov.conf  (by ppp software)
   this causes a hassle.  Just don't use RCS on them,
   but it's a learning process to figure out which ones
   are in this category, and can be a head-scratcher when
   it does cause a problem.

 - forgetting to unlock a file after editing.  It's
   tempting to see if an edit works before committing it,
   and easy to forget which causes a hassle when...

 - 'logname' issues: might su, edit a file, neglect to unlock it,
    re-boot, then find your logname when logged on as
    root is not the same as when you su'd so you have
    to break 'someone elses' lock.  Not a big deal, but
    a hassle non-the-less.


 - Tom

Want to link to this message? Use this URL: <>