How I keep all my config files under version control

Saturday, December 15. 2007

How I keep all my config files under version control

Ah, a Saturday morning that I should spend studying for my exam on Wednesday... What better thing to do than get all my important config files under version control?

Executive summary

To get all my config files under version control, I:

Moved all my important config files to ~/.config/
Put ~/.config/ under version control
Wrote a script to make links from ~/.config/* to the Right Place (ie: ~/.config/vim -> ~/.vim)
All my machines are in sync

So, the problem: I use three machines on a regular basis (my laptop, my server, my computer at work). I want to keep all my important config files in sync (ie: Bazaar and Vim). I'd also like to keep them under version control (version control is a good thing, right?) Can both happen at once? Well, with the magic of bzr (or your favourite distributed version control tool), it turns out they can

The first step was to collect everything into one place. I moved the files I'm going to care about (in this case, ~/.vim, ~/.vimrc and ~/.bazaar) into ~/.config and put that under version control: cd ~/.config; bzr init; bzr add * (it's worth noting that I had some problems with a couple of the bzr plugins which were under version control... Bzr didn't want to add them to my repository because they themselves were repositories. That problem was fixed with a quick rm -r <plugin>/.bzr though).

The next step was replacing the old config files with links to the new (versioned) ones. That was nothing a simple shell script couldn't solve, though (take a look at install_links.sh if you're interested in now it works).

Beautiful. Everything is versioned, I've just got to distribute it.

Bazaar (and just about every other distributed VCS out there) has some wonderful facilities to push/pull it's repositories. All it took was a quick bzr push sftp://wolever.net:443/home/wolever/.config/ to move it over, then sshing over, checking out the files and installing the links:

  $ ssh wolever.net
  $ cd .config
  $ bzr co .
  $ ./install_links

Finally, I put a link to the repository in a web-facing directory (http://wolever.net/~wolever/conf) so I could grab it from my work machine using bzr get http://wolever.net/~wolever/conf/ ~/.my_config (I have to use ~/.my_config because some program (I suspect XFCE) is using ~/.config).

And that's all there is to it

Posted by David Wolever at 15:05 | Comments (7) | Trackbacks (0)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

"Ah, a Saturday morning that I should spend studying for my exam on Wednesday"

I think I messed up worse than you. I started reading about how SQL sucks the night before a database exam

#1 Rudolf Olah (Homepage) on 2007-12-16 02:33 (Reply)

haha I'm terrible at that sort of thing. My train of though would be: "WELL... SQL DOES have a lot to do with databases... So I can justify learning about it"

#1.1 David Wolever (Homepage) on 2007-12-16 18:52 (Reply)

Actually, using ~/.config is a freedesktop.org recommendation (it is the default value for XDG_CONFIG_HOME). Xfce respects several fd.o specs. When I take time to version my dotfiles (using Mercurial), I’ll probably use .config/manual or some other subdirectory (and version the whole .config).

Have you looked at etckeeper for autmatically managing /etc in a VCS? I found can’t-live-without-it posts on the Web, but I’m not sure I agree.

Cheers, Merwok

#2 Merwok on 2009-02-06 20:37 (Reply)

Hrm... Yes, next time I setup a Linux machine which is running some sort of X, I'll put all my stuff in ~/.config/dotfiles or something.

And, no, I haven't seen etckeeper... Wow, that's exactly what I need! Up until now I've just been using vanilla bzr... But that doesn't keep track of permissions, which is a pain.

Probably the most use I've gotten from keeping /etc/ under version control is when I apt-get install a new package and I have no idea where its configuration files are (/etc/programrc? /etc/program/programrc? /etc/defaults/program? Some other sadistic scheme?), I just run bzr status and I can instantly see what has been changed. Also, it's nice on a shared machine because I can quickly tell what the other admins have broken ^_^

#2.1 David Wolever (Homepage) on 2009-02-09 08:28 (Reply)

Actually, /etc/default/program contains the configuration for the init script in /etc/init.d/program, whereas /etc/program (or /etc/program/thing, same thing to me, bash completion takes me to it anyway) is the configuration of the program itself. For example, /etc/mpd.conf contains the configuration for the Music Player Daemon, and /etc/default/mpd contains one or two options which control whether mpd should be run at startup.

File Hierarchy Standard for teh win.

Man, I’ve been here one year ago, and I haven’t found time to code my own dotfiles-in-vcs scripts :/

As for etckeeper, it would be nice to integrate it with ucf. I don’t use “status” like you do, I prefer to ignore everything and add files on a per-case basis, so that my repo contains only files I edited.

BTW, vanilla Mercurial tracks file permissions.

Regards, Merwok

#2.1.1 Merwok on 2010-01-21 22:39 (Reply)

Ah, glad to see you back!

And, yes, you're right - the configuration is logically separated… But that assumes that (a) software is logical and (b) I'm smart enough to know which files need to be edited (I've installed a couple packages which have a flag like FOO_CONFIGURED=false in their /etc/foo/defaults, and they (silently) fail to start unless FOO_CONFIGURED is set to true. So it's nice to simply know all the config files I could need to edit to reduce the search space when something doesn't work.

What is 'ufc'?

And… Sorry - none of git, hg or bzr track file permissions Try:

$ hg init foo
$ cd foo
$ touch secret_file
$ chmod 600 secret_file
$ hg add secret_file; hg ci -m 'adding secret'
$ cd ..; hg clone foo bar; cd bar
$ ls -alh secret_file
-rw-r--r-- …

#2.1.1.1 David Wolever (Homepage) on 2010-01-21 23:12 (Reply)

Software should be logical. In Debian, we have a detailed packaging policy, with an automated tools (lintian) that checks for conformance, and a broad community who reports bugs.

The existence and role of /etc/default has to be learned only once. When my computer boots, I get a message “Not starting mpd: disabled by /etc/default/mpd”; some other programs use a special file in the Debian package that gets displayed upon installation, warning me that they won’t be started unless I enable it. But well, I’m a user advanced enough to read the messages at boot and to use a command-line package manager, so I think you’re right when you say these things can be non-obvious.

ucf is a program that updates configuration files in Debian. If /etc/program has not been modified locally and has a newer version, ucf will replace it with a newer one, else it will prompt me for directions. I can accept the new version, keep my old one, see a diff, or run a shell to manually merge. I wish it were etckeeper-aware.

You’re right about Mercurial and file permissions: it only tracks the executable bit. Hooks and external programs can work around this limitation: http://stackoverflow.com/questions/1289816/can-mercurial-be-made-to-preserve-file-permissions#answer-1291508

Best regards

#2.1.1.1.1 Merwok on 2010-01-23 01:59 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Standard emoticons like :-) and ;-) are converted to images. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: Markdown format allowed You can use [geshi lang=lang_name [,ln={y\|n}]][/geshi] tags to embed source code snippets
	Remember Information? Subscribe to this entry