Using mercurial for configuration files version control

Vadym Chepkov vchepkov at gmail.com
Thu Nov 25 14:42:52 UTC 2010


On Nov 25, 2010, at 9:20 AM, FELD Boris wrote:

> 
> 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.

I was hoping to avoid having to maintain additional templates/parsers/hooks
Let say I enabled snmp daemon

# hg diff
diff --git a/rc.conf b/rc.conf
--- a/rc.conf
+++ b/rc.conf
@@ -11,3 +11,4 @@
 inetd_enable="YES"
 pf_enable="YES"
 pflog_enable="YES"
+bsnmpd_enable="YES"


this is absolutely a trivial change and the diff should be applied to other nodes effortless, I would expect.


> 
> 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 :  "http://You r_node_adress:8000/graph"
> 

As I said, the head is created regardless, is rc.conf involved or not, so I don't think is normal and certainly something I would like to avoid.
I basically need a tool that can track and apply "patches" for me and I was hoping mercurial is capable to do this.

Thanks,
Vadym

> 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 doing 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20101125/113183d4/attachment.html>


More information about the Mercurial mailing list