We have a homegrown config management system and we'd like to add config file versioning to it in a simple way. My first thought was svn (or similiar), but I'm concerned with creating a repo in one location, just to check it out in another location on the same system. In this case we have no use for remote or even multiple checkouts. Is there a software versioning system that lives in one location (metadata+working copy) and will store only deltas? Some of our configuration nodes have large tarballs and binary installers.
3 Answers
Disks are cheap; networks are fast; data loss is no fun (been there, lost a couple of weeks of work). Having a repository in a separate location is a feature, not a bug. It costs pennies and can save you a lot of grief.
That said, if you really want to go down that path, maybe you can look at using a modern filesystem with built-in snapshotting. On Solaris I've used ZFS snapshotting as a poor-man's version control for years. On Linux, btrfs may well be getting close to usable.
![](../../users/profiles/82470.webp)
- 3,702
- 15
- 23
-
This is solid advice Tom. I may just go down the road of using one of our central svn servers for this purpose. I'm still curious if any sort of in-place versioning system exists. – Kyle Smith May 27 '11 at 14:05
-
In-place versioning exists (e.g. the venerable `SCCS` and `RCS`) but I can't think of any one that would also handle binary deltas. But yes, please do use a separate server :) – Tom Shaw May 27 '11 at 14:08
-
1@Tom: DVCS do great in-place versioning. – raphink May 27 '11 at 14:11
-
@Raphink: A DVCS by nature can't store binary deltas. A DVCS relies on the ability to merge and branch based on changesets, but it is not possible to do this with binary files. You need locking in order to use binary deltas, and that means a central repository. – Tom Shaw May 27 '11 at 14:23
-
@Tom: right. That said, @Kyle is asking for a versioning system for his configuration files. On Unix/Linux systems, I yet have to find configuration files that are blobs. – raphink May 27 '11 at 14:27
-
@Raphink: [Configuration management](http://en.wikipedia.org/wiki/Configuration_management) is a broader concept than just configuration files. Also, the author specifically mentioned large binaries and the requirement for deltas. – Tom Shaw May 27 '11 at 14:31
-
@Tom: Ah right, seen this way. But then if it's for more than configuration files, I'd really go for a centralize system using a real configuration system like `puppet`, `cfengine` or `chef`. – raphink May 27 '11 at 14:33
-
@Raphink: Good tip. Kyle says he is using a home grown system, but I agree that there's no point re-inventing the wheel. That's a different question though: the current question is about wrapping version control around a configuration management system. – Tom Shaw May 27 '11 at 14:39
Have you considered etckeeper?
It is an "in-place" versioning system which can rely (see its configuration) on most DVCS (hg
, git
, bzr
or darcs
).
It automatically versions all your files in /etc
and commits them automatically every time they are modified.
Since it relies on DVCS, you could even use it to duplicate/backup your configuration using push/pull/mirror/etc.
commands (depending on the DVCS backend you choose).
![](../../users/profiles/29328.webp)
- 11,337
- 6
- 36
- 47
Actually that's not that abnormal. There isn't any functional problem with handling things that way. Most VCS don't deal particularly well with tracking changes in a binary, so it's of less use for tracking changes, but it would still work. If you use a DVCS then you gain some protection against a single system failure. git or mercurial should be available for RH without too much trouble and either should work well for your needs, as would svn.
![](../../users/profiles/20537.webp)
- 1,636
- 2
- 12
- 18
-
My issue is checking all the data into an svn repo located in a location outside my config management node, just to check it out again inside the node. I'm trying to prevent two copies of the data from existing. – Kyle Smith May 27 '11 at 13:31
-
Well, no, not if you're checking it out. I suppose you could create the repo at the files normal location, but if there are lots of files created inside of the repo, you'll end up with a sprawling list of deltas that aren't really relevant to what you're trying to track. – OldTroll May 27 '11 at 13:36