Using mercurial for configuration files version control
Jouni Airaksinen
Jouni.Airaksinen at descom.fi
Thu Nov 25 15:02:09 UTC 2010
Well, nothing says you'd have to use separate files if servers can use the
same files. The need in my case was that servers had different needs, but
configuration had to be in version control in anycase. I guess your
problem is more in the lines "I cannot clone/pull from master repository"
if I understood correctly?
Technically you can move repository into existing directly if you just
clone it first into new directory and then move/copy the content into new
directory (might be possible just to move .hg directory and do update in
the new directory). I probably would prefer having separate directory and
then just symlink wanted files. Of course this cannot track new files and
you'd have to setup the symlinks manually, but atleast you won't "kill"
your servers that easily.
From: Vadym Chepkov <vchepkov at gmail.com>
To: Jouni Airaksinen <Jouni.Airaksinen at descom.fi>
Cc: mercurial at selenic.com
Date: 25.11.2010 16.52
Subject: Re: Using mercurial for configuration files version
control
Sent by: mercurial-bounces at selenic.com
On Nov 25, 2010, at 9:44 AM, Jouni Airaksinen wrote:
In one project I had setup for application specific cronjob configurations
and the jobs were different for each server in the cluster (not equally
balanced system and some services were fixed to certain servers). It was
solved so that in the repository had separate files for each server and
each server was just configured to use those certain files (either
directly or through symlinks). Then each server cloned/pulled changes from
one main repository. Whole thing was orchestrated with Capistrano.
But this would imply I have to maintain many instances of exactly the same
file except 2/3 line and don't forget to apply the same changes in those
copies. :(
Whatever depends on "not forget" is bound for failure in my opinion.
Vadym
From: FELD Boris <lothiraldan at gmail.com>
To: Vadym Chepkov <vchepkov at gmail.com>
Cc: mercurial at selenic.com
Date: 25.11.2010 16.19
Subject: Re: Using mercurial for configuration files version
control
Sent by: mercurial-bounces at selenic.com
Hi,
I am not sure to understand all of your problem, but i can give you my
point of view.
The situation you describe is a common problem with dcvs where every
developer must adapt configuration files to his system.
The solution is quite simple, you just track a template version of your
configuration file.
In your case, the template version could be very short :
hostname=""
ifconfig_bce0="inet 192.168.17. netmask 255.255.255.0"
You named this file /etc/rc.conf.tpl and track this file into mercurial.
Then for each node, you create a local file based on this template file.
For the second problem you describe, it's normal. If i resume your
process, on each node :
- You pull from "master" (rev 1)
- You modify /etc/rc.conf and commit locally (rev 2)
- After a modification on "master" repository, you pull from "master" (rev
3)
The problem is when you commit locally your changes on /etc/rc.conf,
master repository not contains this changeset and when you try to update,
mercurial does not know to which repository to update.
To visualise this situation, go to your local repository, type this
command "hg serve -v". Then launch your webbrowser and go to this adress :
"ht tp://You r_node_adress:8000/graph"
I'm not sure i was clear, i hope it help you
--
FELD Boris
Sent with Sparrow
On jeudi 25 novembre 2010 at 14:54, Vadym Chepkov wrote:
Hi,
I am trying to use mercurial for tracking / populating configuration files
and I am facing some obstacles I need help to overcome.
The technique works quite well with a standalone host. I usually do this:
cd /etc
hg init
cat > .hgignore <<EOF
syntax: glob
*
EOF
hg add .hgignore
hg commit -m "Starting with empty set"
Then I add all files I modify to the repository and track changes that
were made.
Now I want to use this repository to populate configuration among members
of a cluster, because all changes that are made almost always absolutely
the same on all nodes.
First challenge - I am not able to clone remote repository into an
existing /etc directory on a second node - there is no such thing as
"force", at least I wasn't able to find it.
So, instead, I did hg init on the second node and did hg pull
ssh://master//etc/ . This concerns me a bit, because the repositories
don't have a common "parent", don't know how essential this is.
Anyway, all works well until I added /etc/rc.conf into repository. This is
one of those seldom cases where some lines in the file are different on
every node.
for example, on master node
hostname="master"
ifconfig_bce0="inet 192.168.17.254 netmask 255.255.255.0"
on slave:
hostname="slave"
ifconfig_bce0="inet 192.168.17.253 netmask 255.255.255.0"
After I pulled form master's mercurial, as expected, overwrote local
rc.conf, so I modified those few lines in it and committed these changes
locally, without any future intents to push any local changes back to
master.
And now I have a second challenge. Now every time I pull from the master
it creates a new head I have to merge and commit, even changes that has
nothing to do with rc.conf, but even then, if I just add one single line
to the end of master's rc.conf, I would expect mercurial to be able to
duplicate this simple delta without do ing any manual merges.
I realize not many use mercurial this way, so I had to describe the task
in details, but I don't think I am trying to do something unreasonable and
would appreciate your advice to how to do it properly.
Thank you,
Vadym Chepkov
_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial
_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial
_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20101125/ae37a0d3/attachment.html>
More information about the Mercurial
mailing list