[TAG] Version control for /etc

[Paul Sephton]

On Fri, 2007-10-26 at 15:39 +0530, Kapil Hari Paranjape wrote:
> Hello,
> 
> On Fri, 26 Oct 2007, Thomas Adam wrote:
> > [git]'s very good, but not so good for something
> > like /etc -- since its permissions model is something to desired.
> 
> A solution to this problem which is used in a slightly different
> context (user home directories rather than /etc) is to use an update
> hook.
> 
> 	http://kitenet.net/~joey/cvshome/ (using CVS)
> 	http://www.onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html (using SVN)
> 

I have been following this thread, and thought to share an interesting
approach with you.

Back in the days of the PDP-11, RSX-11M OS used to version each file as
it changed.  Only once you did a 'purge' command, would the earlier
versions be removed.  That was hugely useful.  The latest file would be
named 'filename', and all other versions of the same file would be
'filename;1', 'filename;2', etc.

A version control system such as rcs is cool enough, I suppose, and
common to most platforms as well. It does take a bit of knowledge of
ci/co etc. to drive, and has the disadvantage that you only see the
currently checked-out file at any given stage.

In the early days of playing Linux, I wrote a script that traversed a
directory using 'find', and created hard links to each file in a target
directory and subdirectories.  The hard links and duplicate directory
structure were saved in a separate base directory on the same volume.
Yup, you guessed it- I used file name extensions ;1, ;2 etc. for their
unique versions.

So long as your editor created a new file rather than just rewriting the
same inode, a regular cron of the script ended up in keeping my
versioned files for me.  I never lost a thing after that, and could
always go back to see change history.

As the file was always linked in the backup directory, you could delete
the original and restore it again effortlessly.  The use of hard links
meant that hardly any additional disk space was used unless you actually
edited a file, resulting in a new inode and hence a new version (when
cron got around to it).

Paul