Hg by email

Tue Jul 27 23:08:13 UTC 2010

* Tony Mechelynck on Tuesday, July 27, 2010 at 21:41:51 +0200
> On 27/07/10 20:53, Michael Brian Bentley wrote:
>> Tell me if I'm off base. It has taken a little bit of work to figure
>> this out on paper, and I may not be even remotely correct.
>> 
>> I want to use mercurial to keep three completely independent machines in
>> sync on a project.
>> 
>> The project originates from one machine; subsequent contributions can
>> come from all three. The machines can only communicate by email or
>> sneakernet.
>> 
>> We want a best-effort way to keep our local repositories in reasonable
>> sync with each other, without being militant about it. We want Hg to
>> help us stay in sync and help keep track (despite the lack of immediate
>> automatic network gratification).
>> 
>> 
>> 
>> As I understand it,
>> 
>> A local repository is created on the first machine using hg init.
>> 
>> On the first machine, a set of original files to the repository are
>> added, and the change committed.
>> 
>> At the original machine, you can't "push" the repository to the other
>> two machines, because push does not work via email. Instead you have two
>> options, the first being to use the hg bundle command:
>> 
>> hg bundle -a bundlename
>> 
>> to create the file bundlename.bz2 that in this case contains all
>> changesets to date in a bzip2 file. This file can then be emailed as is
>> to the other two machines, to establish an exact copy of the original
>> repository by using the command:
>> 
>> hg unbundle -u bundlename.bz2
>> 
>> Q1) Does this create repositories on the second and third machines, or
>> do we have to precede the unbundle command with something like hg init?
>> What's the best way to establish these other two repositories for this
>> project so that each machine has a revision history that is at least
>> somewhat aware of where the other two machines are?
>> 
>> Subsequent bundles should be sent with specific changesets in mind using:
>> 
>> hg bundle -r changeset
>> 
>> Use of the incoming and outgoing commands appear to be not very useful
>> in this mode of operation because they require more direct and immediate
>> communication with the other repositories.
>> 
>> 
>> I also looked at a second option, patch export, import (and queues).
>> This approach seems more independent and resilient but less verifiable.
>> 
>> We desire to have our machines be somewhat aware of where the others
>> are, so information that comes via email is greatly appreciated.
>> 
>> Interestingly, full knowledge of the state of each machine in this case
>> really is dependent on what each programmer says it is, since I don't
>> have any way to directly contact the remote machines.
> 
> IIUC, not only you can't push, but you can't pull either, or even
> run hg incoming or outgoing, since all of these require an http
> connection between client and server if they are on different
> machines.

You can do /some/ stuff with bundles, e.g.:

hg incoming bundle.hg