Keeping 2 disconnected sites in sync

[Paul Moore]

Another newbie question, I'm afraid :-( Thanks for your patience so
far, please bear with me a little while longer as I get to grips with
what I can do with Mercurial...

I have a couple of separate sites where I work on some projects - home
and work, basically. Unfortunately, I have essentially no network
connectivity between the two. My work PC can only access HTTP and FTP
on the internet (firewall restrictions) and my home ISP limits me to
static files over http, and an FTP area. So I can't host a Mercurial
repository that's available to both.

I've therefore been looking at other options for keeping the 2 sites
in sync. I'd appreciate any comments or alternative options.

The simplest option is to keep a master repository on a USB key. This
is technically ideal, but procedurally a pain - I tried it before with
a Subversion repository, and found I was forever forgetting to plug in
the key and commit. So I don't expect to be any more disciplined with
Mercurial...

Another option I've considered is to copy (filesystem copy, not hg
clone) a master repository between my PC and my FTP space at the start
and end of each session. That's OK as long as there are no overlaps,
but if (for example) I forget to do the copy one day, I end up with
unmerged work at both sites. This is a pain, as it's one of the uses I
want to allow.

A third option might be to use hg bundle and email bundles between the
sites. But I can't see how to do this, as I get the impression that hg
bundle needs to see the target repository in order to decide what
changesets to include. I might be able to do it with a "master" and a
"working" repository on each PC, but then I start getting lost in a
maze of repositories, so I suspect that will become unmanageable.

I'm starting to think that the USB key approach is the best - using
Mercurial's better support for disconnected operation and better
merging to deal with my lousy discipline :-)

Does anyone have any comments on the above, or suggestions for a
better approach?

Thanks,
Paul.