Ryan Anderson <ryan@michonline.com> writes:

quoted text
> Junio C Hamano wrote:
>> Adam Hunt <kinema@gmail.com> writes:
>> 
>> 
>>>Do you have any more details by chance?  Does it work?  Does it work
>>>well?  How does one do it?
>> 
>> 
>> I personally feel it is a horrible and stupid thing to do, if by
>> "version control /etc" you mean to have /.git which controls
>> /etc/hosts and stuff in place.  It would work (git does not
>> refuse to run as root).  But being a *source* control system, we
>> deliberately refuse to store the full permission bits, so if
>> your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
>> have to make sure they stay that way after checking things out.
>
> This is, admittedly, a major problem.

An SCM is not a replacement of a backup.

quoted text
>> You are much better off to keep /usr/src/rootstuff/.git (and
>> working tree files are /usr/src/rootstuff/etc/hosts and
>> friends), have a build procedure (read: Makefile) there, and
>> version control that source directory.  I usually have 'install'
>> and 'diff' target in that Makefile, so that I can do this:
>>... 
> If you're doing this, especially if you're doing this on multiple
> machines, creating a package is probably a worthwhile thing to
> contemplate as well.

In my workplace environment, the equivalent of the above
/usr/src/rootstuff is accessible throughout the networked
machines (mostly NFS mounted); for things that needs per-host
customization, we do not have /usr/src/rootstuff/etc/hosts but
keep /usr/src/rootstuff/etc/hosts.in as the source, and Makefile
customizes that into a form suitable for installation for each
machine.  Especially useful is vfstab.in --- a single source
builds fstab for local mounting and nfs exports, while other
machines have mountpoints and project symlinks pointing into
location automounted from that machine with disk, generated
automatically.  This does not match typical "package" use.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html