Date: Sun, 29 Mar 2009 15:11:54 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Glen Barber <glen.j.barber@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: [OT] - Best Practices(TM) for Configuration File Changes Message-ID: <87bprkbkad.fsf@kobe.laptop> In-Reply-To: <4ad871310903290437q269964d7k54a449f405fb31b2@mail.gmail.com> (Glen Barber's message of "Sun, 29 Mar 2009 07:37:27 -0400") References: <4ad871310903290437q269964d7k54a449f405fb31b2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 29 Mar 2009 07:37:27 -0400, Glen Barber <glen.j.barber@gmail.com> 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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87bprkbkad.fsf>