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