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
http://www.linuxjournal.com/article/7712 and automates some of the rsync coordination of two folders. Hope this helps, -tim _______________________________________________ Blinux-list mailing list Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list