A Centralized VCS For Config Files
Version Control Systems are programs that maintain a history of edits or changes to a collection of files.
I often want to use versioning for individual isolated files, or collections of files, that live somewhere in my directory tree. However, because management of many independent repositories is hard, I am reluctant to create and maintain a repository wherever the file lives if the directory itself is not under active development.
Some examples of files like this are dotfiles in my home directory, and other preference or configuration files throughout my directory tree.
Instructions
Here's a solution that was based on a suggestion by Casey Dahlin on Doug Warner's blog. Comments from Peter Manis, Benjamin Schmidt and Martin Geisler were also helpful here, here, and here.
The idea is to create and manage a single repository for these files that will be easy to manage. Files can be added manually. Regular commits will be made on an ongoing basis, and can even be automated.
Initialization
First, create the repo in your home directory
cd $HOME
hg init
Safety Precautions
Peter Manis points out that the hg purge command can remove all files in the working directory that are not added to the repo!! He advises to explicitly disable this command for the repo by adding the following to the project-level .hgrc file located in $HOME/.hg/hgrc
[extensions]
hgext.purge = !
List, Add, Forget, Remove, Commit, & Status
You can list, add, forget, remove, and commit files to the repo with the following commands
hg manifest
hg add <files>
hg forget <files>
hg remove <files>
hg commit -m "Added/removed/changed file(s)"
The status command reports on all files in the working directory whether they have been added to the repo or not. This can take a long time.
hg status
The Default Repo
To access the centralized repo from directories other than your $HOME directory, set the default path in your user-level .hgrc file located in $HOME/.hgrc
[path]
default = $HOME
The centralized repo is accessible only if the current working directory (PWD) is not itself the working directory of another repo.
Warning: A danger of using this preference is that you may end up using the centralized repo when you intended to use a local repo. For example, if you accidentally call hg from a non-versioned directory.
To identify which repo you are working on, just type
hg showconfig bundle.mainreporoot
An easier solution is to add the following to your user-level .hgrc file
[hooks]
pre-status = echo "======\nMAIN REPO ROOT = $PWD\n======"
pre-manifest = echo "======\nMAIN REPO ROOT = $PWD\n======"
This way, whenevery you type hg status or hg manifest, you will be told which repo is active.
The .hgignore File
An alternative strategy for managing repo files, is to create an .hgignore file listing the files that you do not wish to be tracked, and then add / commit everything else.
A simple .hgignore file looks like this.
syntax: glob
*~
.*.swp
*.swp
*.o
.hg
syntax: regexp
^[a-zA-Z]
.file1
^\.file2\/file3
This file excludes several standard temporary files, any file named ".file1", and files matching "file2/file3" in the repo's root, working directory.
After editing the .hgignore file to your liking, you can preview your choices with
# 1. show "added" files (will be included in the next commit)
hg status -a
# 2. show "unknown" files (will not be included in the next commit)
hg status -u
Then, you can use the following shorthand to: 1) add all unknown files and commit the changes to the repo, and 2) view, the resulting contents
hg commit -A -m "Added/removed/changed file(s)"
hg manifest
File & Directory Sizes
One trick for building .hgignore is to detect and exclude LARGE dotfiles and directories. At first, I tried to these using
ls -lSd .* | head -20
However, ls does not measure the size of directories when reporting relative size. To see the largest items accounting for the total size of directories,
use the following
for X in $(du -s .[a-zA-Z]* | sort -nr | cut -f 2); do du -hs $X ; done | head -20
This will produce sorted output, for example
8.2G .Trash
99M .dropbox
21M .m2
19M .groovy
6.0M .macports
3.7M .vim
1.8M .fontconfig
976K .ipython
...
Resetting The Repo
If you are not happy with the current manifest, and are willing to start again from scratch, use the following commands. WARNING: This will erase any history!
cd $HOME
\rm -rf .hg
hg init
hg commit -A -m "Added/removed/changed file(s)"
hg manifest
This can be used to refine the .hgignore file in order to initialize the repo
Glossary
Current Working Directory : PWD
Working Directory : "To introduce a little terminology, the .hg directory is the “real” repository, and all of the files and directories that coexist with it are said to live in the working directory. An easy way to remember the distinction is that the repository contains the history of your project, while the working directory contains a snapshot of your project at a particular point in history." quote
Hg Init : Create a fresh repo. Fails when an existing repo exists in the working directory.
Hg Manifest : List files currently in repo
Hg Add : Add a file to repo
Hg Forget : Forget files previously added to repo, before committing
Hg Remove : Remove files previously added to repo, after they have been committed
Hg Commit : Commit all changes to repo
blog comments powered by Disqus