Using mercurial to track host configuration

Matt Mackall mpm at selenic.com
Mon Jun 19 18:00:10 CDT 2006


On Mon, Jun 19, 2006 at 03:28:29PM -0700, Gil wrote:
> I'm new to mercurial and would appreciate any advice that the list
> gurus have to offer.  I'd like to use mercurial to track
> configuration changes on UNIX hosts and have a few comments and
> questions.
> 
> Mercurial is particularly attractive for host configuration
> management because it doesn't leave little CVS or .svn turds lying
> around everywhere.  These cause problems with some programs that
> expect to use all files in a directory as configuration files (e.g.
> /etc/logrotate.d for logrotate).  Also, not having to use a central
> repository removes all sorts of machine inter-dependencies that I'd
> rather avoid.
> 
> 
> I'd run into a problem with mercurial 0.9 in that I couldn't use a
> repository in the root directory:
> 
> cd /
> hg init
> hg status
> abort: path contains illegal component:
> 
> I found and applied this patch to make things work:
> 
> http://hg.intevation.org/mercurial/crew?cs=3711e23ab10a
> 
> It would be fantastic if this patch made it into the next stable
> release of mercurial.  (I think it may have been addressing issue
> 228 but can't be sure.)

Yep, this should be fixed in the next release. That might be soon if
people would only stop sending me interesting new code.

> One use case I'm not clear on is how to re-apply configuration
> changes against a new copy of a machine with an updated OS.  With
> CVS this was frustrating because I'd have to do something like this
> to review what changed without killing the local files:
> 
>     cd /var/tmp
>     cvs co machines/`hostname`
>     cd machines/`hostname`
>     find . -type d -name CVS | xargs -i mv {} /{}
> 
> At this point I could use the usual cvs diff and friends to review
> what changed between my working configuration and the new OS.
> 
> Assuming I hg push to an off-site location or keep backups of my
> /.hg* files do I get similar behavior from mercurial just by
> restoring /.hg* onto the new machine?

You should be able to do the appropriate push/pull (pull is almost
always a better model for clients, btw), then do hg diff -r tip to
compare the current working dir (eg /) with the tip revision.

> Are there any other pitfalls others are aware of when it comes to
> this kind of usage?  Is anyone else tracking machine configuration
> in this way with any degree of success?

The big pitfall is that Mercurial only tracks execute permissions. In
general, we try to deal with a minimal subset of metadata and because
owner/group/mode are not generally portable/relevant from system to
system, we don't track them.

So to track group/owner/mode, you'll need to do something like add a
permissions.lst text file and a hook that applies the permissions on
checkout.

-- 
Mathematics is the supreme nostalgia of our time.


More information about the Mercurial mailing list