Re: Advice on choosing git

[Joe Brenner <doom@kzsu.stanford.edu>]

Noah Silverman <noah@smartmediacorp.com> wrote:

> I'm looking for both a version control system and backup system.

I had a similar thought some time ago.  I thought that putting my life
inside of a distributed version control system (my first thought back
then was Monotone) would also be a convienient way to handle the
laptop-workstation sync problem.

But:

> 1) Size.  THIS IS MY MAIN CONCERN - If I want to sync my home, office,
> and server Document directories.  From what I have read, I will
> effectively have multiple copies of each item on my hard drive, thus
> eating up a lot of space

Pretty much any version control system is going to have this problem,
and it gets really bad if you've got any files that aren't straight text.

You won't get any benefit out of things like "git diff" either.  The
diffs we have (these days at least) don't work well on anything but plain
text.

I suggest you stick to using git down on the project level, where a
project should be limited to things like code development (or writing
projects where you stick to text formats), and give up on any ideas like
putting your entire home directory into a single repository.

As far as mirroring machines go, rsync based solutions actually aren't
that bad, though in addition to the annoying syntax gotchas, I've had
problems with an unreliable laptop clock.  Lately I've been using the
"--size-only" option of rsync, which assumes that if a file is bigger
it must be newer.

I tend to use a perl script something like this, which copies newer
stuff from a given directory to an analogous directory on a remote
machine:

  use File::Basename qw( dirname );
  my $this  = shift;   # e.g. '/home/doom/dev/code
  my $there = shift;   # e.g. 'doom@192.168.1.3'
  my $this_loc = dirname( $this );
  $cmd = "rsync -avz --size-only -e ssh $this $there:$this_loc";
  system( $cmd );