(D)VCS for $HOME mirroring

Many people use a Version Control Systems to mirror their $HOMEs in several networked computers. This has clear advantages of doing incremental backups of your $HOME (TimeMachine, anyone? :-)) and keeping it in sync across several computers. In the past, I’ve used Mercurial to do this job, but some months ago I switched to Subversion because I wanted to use try the one-VCS-for-all meme (Subversion is now being used by FreeBSD in case you don’t know). Unfortunately, it didn’t work out well. The computer where I kept the svn repo had a horrible hard disk failure and this made me wonder if I was using the right tool. Today, I switched back to Mercurial and I guess this is the right tool for the job.

5 thoughts on “(D)VCS for $HOME mirroring

  1. Yep. Mercurial can be useful for this sort of thing.

    I managed to botch my Linux testing machine at home a few days ago.

    Having `linuxhost:/home/keramida’ in an hg clone, was quite a refreshing thing. I popped a gNewSense CD-ROM into the drive of the broken system, installed a development system (compilers, debuggers, and autotools) with that distribution, created a `keramida’ user and installed Hg with apt-get.

    Then I just run from my backup/clone host:

    % cd /hg/home
    % scp linux-home.hgrc.sample linuxhost:.hgrc
    % scp linux-home.bundle linuxhost:
    % ssh linuxhost
    linuxhost> hg init
    linuxhost> hg pull linux-home.bundle && \
    rm -f linux-home.bundle

    Bang! ‘Instant’ setup of gdb, vim, Emacs, and a few other tools :-)

    Naturally, this means that a backup script should bundle all the new changes and push them to the backup host every now and then. But this is easy to set up, and I really liked having the full history around.

  2. Could you possibly explain in more detail how you set it up and how actually you use it (hg) please ? :)

  3. mato,
    Certainly. you basically need to::
    % hg init
    % hg add .exrc .vimrc .emacs (etc..)
    % hg commit

    Now you have your home under hg.

    When you want replicate this to another machine, go to the other machine and type:
    % hg clone ssh://machine_where_you_did_hg_init

    Now every time, you change something in the first machine, you just need to do ‘hg commit’. On the second machine simply do ‘hg pull && hg up’.

    If you change something on the second machine, just do ‘hg commit && hg push’. The changes will show up on the first machine. But please note that, you need to do an ‘hg up’ and resolve any conflicts, if any, for the files to be actually modified.

    That’s basically how distributed scm works.

  4. Thanks, Rui!
    However I was looking for some more advanced usage and ideas.
    For instance, I get a new account on a new server and I want to set it up but .. some files are ok (like .vimrc), some might need to be a little different (a config file patched because of different hostname, screen resolution, installed sw, etc.) and some might not be appropriate at all (eg private).
    Or what if I would like to transfer files which I don’t want to be versioned (they might be binary, huge, change often or otherwise versioning them may not make sense or is undesirable).
    These are some of the situations I’ve been trying to solve but haven’t succeeded to my full pleasure.
    Cheers! :-)

  5. For different machines, I basically do shell script machinery.
    For different software installed, I don’t really care. I just sync everything among every machine.
    For private files, they, obviously, don’t go into the repository. One could say that all the files in the repository are private, which is true, but some are more private than others.
    Binary files don’t go into my repo either. I deal with these by hand since I usually have none that could be versioned.

Comments are closed.