syncing mail and address book

Tim Chase blinux.list at
Sun Mar 30 11:11:05 UTC 2008

> Tim Chase also makes a point, although I personally don't agree with his 
> method having used rcs before. If you're worried about losing mail or if 
> you want undelete ability, use a version control system. Debian has the 
> rcs package which is what I would suggest. You have to check out your 
> mail folders every time and check them back in when you're done reading 
> email. To me, that seems like a big pain and still won't mirror your 
> mail to and from your laptop. 

RCS is a very limited old-school VCS.  It doesn't have strong 
network support, and doesn't have a way to easily track the 
moving of files.  CVS took RCS and made it more network aware, 
and allowed for concurrent (the "C" in "CVS") editing.  But 
things have come a *long* way since RCS.

The new generation of VCS programs have stronger support for 
networking, directory-content tracking, and other such nicities. 
   I still use RCS for simple single-file cases because it's easy 
to set up and get going.  However, for anything more complex, I 
use one of the newest VCS programs.

With Subversion (SVN), you'd create a central repository on some 
machine that's always on (whether a home desktop machine, or a 
hosting-service machine with SVN access).  When you're done on 
one machine, you commit your mail directory to this repository 
with a simple "svn commit".  Then, from your other machine, you 
can update from this remote repository with "svn update" ("svn 
up" if you're lazy like me) which will automatically synchronize 
your inboxes.  Then you repeat the process of committing, 
switching to the other machine, and updating.

With Distributed VCS (DVCS) programs like Mercurial (hg), Bazaar 
(bzr), Git, and Darcs, they're a little smarter about merging 
changes from one archive to the other--they can be used in a 
non-distributed fashion in the same way as SVN, or they can be 
used in a distributed fashion which gives you more flexibility in 
your event sequencing.  You just commit regularly wherever you 
are, then occasionally pull from the other side when you have the 
machines together.  Conflicts can occur (and you'll be notified 
if there are problems), but I've not had anything that was too 
hard to resolve.

This isn't to knock rsync, because it's a great tool (and I do 
use it too).  I think it's mostly designed for efficiently 
cloning a directory, but not so much for keeping two directories 
in sync.

One last option one might investigate is Unison, which is written 
up nicely at

and automates some of the rsync coordination of two folders.

Hope this helps,


More information about the Blinux-list mailing list