What is a good Mercurial usage pattern for this setup?

Question

We've got two developers on the same closed (ugh, stupid gov) network, Another developer a couple minutes drive down the road, and a fourth developer half-way across the country. E-Mail, ftp, and removal media are all possible methods of transfer for the people not on the same network.

I am one of the two closed network developers, consider us the "master" location.

What is the best Mercurial setup/pattern for group? What is the best way to trasmit changes to/from the remote developers? As I am in charge, I figured that I would have to keep at least one master repo with another local repo in which I can develop. Each other person should just need a clone of the master. Is this right? I guess this also makes me responsible for the merging?

As you can see, I'm still trying to wrap my head around distributed version control. I don't think there is any other way to do this with the connectivity situation.

Answer 1

The twist with no network connect sure is interesting. So the closed network has no way of connecting to the general internet, like http?

Answer 2

Correct. The only way anything makes it onto the closed network is via flash drive.

Answer 3

The users outside the network can make patches, and/or use email to send the updates to the main repo or someone, like yourself to merge them. The other internal people can have local copies, like yourself and do merges --but if you are having these out of network patches, it might be better that one person deal with them so nobody gets confused, but that's something you'd have to consider yourself.

Syncing the other way, you'd create a patch, and them email or get a flash drive to the remote developers to patch their system. You're going to need some good communication in the team man, I am thankful I'm not in your shoes.

Those are my only suggestions --well, the obvious, get them a VPN connection! I'd love to hear how it goes, what plans stabilize into a weekly groove, et cetera.

Answer 4

Patches are a simple and versatile solution.

For moving around larger groups of changes (especially binary changes and merges), Mercurial offers binary bundles. A bundle is basically the binary stuff that is sent on the network when you do hg push, but here it is captured in a file.

Let's imagine I have gotten a clone somehow (by flash drive, DVD, etc.). Call it upstream. I then make a second clone, call it devel. I do all my development in devel and make lots of commits, merges, etc. Since Mercurial is distributed I can do all this offline.

To see which changesets are missing in upstream I do

% hg outgoing ../upstream

When I have something to send, I can use

% hg bundle changes.hg ../upstream

to get a binary compressed file which contain the changesets including all their meta data. I can then burn this file on a CD and send it by mail...

The recipient of the bundle can do

% hg incoming changes.hg

to see the changeset list and

% hg pull changes.hg

to unpack and add the changesets to his repository. He will then most likely have to merge -- this is exactly as if he had pulled directly from your repository over HTTP or SSH.

Note, the upstream repository is only used as a convenient way to remember which changesets are already found in the upstream repository. You can also just jot down the changeset ID and use hg bundle --base when bundling to specify the base (common) changeset. See hg help bundle or look in the wiki.