From owner-freebsd-questions@FreeBSD.ORG Sun Mar 29 12:11:58 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7F4C10656CB for ; Sun, 29 Mar 2009 12:11:58 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 506C88FC13 for ; Sun, 29 Mar 2009 12:11:58 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 1C65BEB524F; Sun, 29 Mar 2009 15:11:57 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 0B73D4503F; Sun, 29 Mar 2009 15:11:57 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xp2S2tf87a2g; Sun, 29 Mar 2009 15:11:56 +0300 (EEST) Received: from kobe.laptop (adsl82-150.kln.forthnet.gr [77.49.49.150]) by mail.ceid.upatras.gr (Postfix) with ESMTP id A8DC545088; Sun, 29 Mar 2009 15:11:56 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n2TCBtOA098182; Sun, 29 Mar 2009 15:11:55 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n2TCBtg8098181; Sun, 29 Mar 2009 15:11:55 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Glen Barber References: <4ad871310903290437q269964d7k54a449f405fb31b2@mail.gmail.com> Date: Sun, 29 Mar 2009 15:11:54 +0300 In-Reply-To: <4ad871310903290437q269964d7k54a449f405fb31b2@mail.gmail.com> (Glen Barber's message of "Sun, 29 Mar 2009 07:37:27 -0400") Message-ID: <87bprkbkad.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-questions@freebsd.org Subject: Re: [OT] - Best Practices(TM) for Configuration File Changes X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 12:11:59 -0000 On Sun, 29 Mar 2009 07:37:27 -0400, Glen Barber wrote: > Hello, list. > > Before I pose my question, I am not intending to start a flame-war of > any sort -- I'm just searching for "different" ways of doing things. > > With so many different version control systems available (aside from > the traditional "keep current backups" solution), I am curious: > > Q: What is *your* favorite/suggestion solution to keep (working) > versions of configuration files, in case something goes awry? > > I am specifically targeting configuration files because they are what > I change the most, in avoidance of "It worked 10 minutes ago..." > situations. The base system of FreeBSD includes RCS[1]. I regularly use it to track changes to individual files. The advantage of RCS is that it is easy to use from a system that is barely `up', i.e. a system that has just been brought up to single user mode. No special daemons or other sort of service is required, no ports to be installed, and so on. I can usually just run something like: [1] http://www.gnu.org/software/rcs/ # cd /boot # rlog loader.conf RCS file: RCS/loader.conf,v Working file: loader.conf head: 1.5 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 5; selected revisions: 5 description: ---------------------------- revision 1.5 date: 2009/03/27 17:58:59; author: root; state: Exp; lines: +2 -1 Autoload acpi_ibm.ko for the extra Thinkpad X61s tunables. ---------------------------- [more output snipped] # Whenever I want to look at a change, I can use `rcsdiff': # cd /boot # rcsdiff -u -r1.4 loader.conf =================================================================== RCS file: RCS/loader.conf,v retrieving revision 1.4 diff -u -r1.4 -r1.5 --- loader.conf 2009/02/17 20:26:14 1.4 +++ loader.conf 2009/03/27 17:58:59 1.5 @@ -9,6 +9,7 @@ legal.intel_iwn.license_ack=1 # Autoloaded modules. +acpi_ibm_load="YES" snd_hda_load="YES" #zfs_load="YES" if_iwn_load="YES" # The co(1) and ci(1) utilities are relatively easy to learn. Whenever a permanent change has to be made, I can use: # cd /path/to/file # rcsdiff -u filename If this shows changes they are probably uncommitted changes I have made without recording when or why. This is usually an indication of some sort of 'temporary hack'. I review the diff, and either commit it or throw it away. Then I check out a clean copy of the file, make the new permanent changes, review the changes one last time with the `rcsdiff' command, and commit them again. # co -l filename # vi filename # rcsdiff -u filename # ci -l filename As an extra bonus, when a system is fully up and running, there is very good integration of RCS with GNU Emacs, so I can edit the files directly from my Emacs session, view diffs with older revisions, roll a bunch of files back or forward through history, and do whatever else is supported by the VC mode[2] of Emacs: [2] http://www.emacswiki.org/cgi-bin/wiki/VersionControl RCS is not really 'modern', i.e. it does not support changesets with multiple files (each file has its own separate, per-file history), and it does not support elaborate file merging techniques (like some of the modern distributed VC systems). But it is always there, it does the Right Thing with file permissions and file ownership, and is well integrated with my favorite editor. That's more than enough for now :)