tags:

views:

41

answers:

1

My team has a local development network which is not physically connected to any outside network. This is a contractual obligation and CANNOT be avoided. We also have to coordinate with a team which located halfway across the country and, as previously implied, has no direct network connectivity to us. Our only method of transferring data involves copying data to a USB disk and sending via email/ftp/etc.

NOTE: Let's not discuss the network connection issue or the obvious security flaw with the USB disk access. These issues are non-negotiable.

We're still convincing the external team to use Mercurial (currently don't use ANY SCM). Assume for the rest of this question that they're using Mercurial. We're going to force their hand any day now.

We switched to Mercurial in hopes of being able to utilize the distributed nature to better sync w/ the external team. Internally, we're using Mercurial much like a central server SCM. Each developer clones from a master repo on your integration server. Changes are pushed/pulled from this central location.

Here lies the actual question content:

What is the best way to communicate changes to the remote team (assuming they're using a similar Mercurial setup to us)? Should I have a local master repo for local push/pull), and a local integration repo for remote push/pull? How can I best avoid complicated merge issues that will arise? If we use Mercurial bundles to push changes, who will do the merges and against which repository?

+1  A: 

You can basically use it in exactly the same way as if you were online.

You just need to replicate the remote repo locally and unbundle every changeset they send you in it. You should never push your changes directly into the local-mirror (it should always reflect the state of the remote team).

Afterwards you decide what you want, doing merges on your side or on their side, it doesn't really matter.

tonfa
Makes sense, I'll likely accept this after a couple days. Gotta give others a chance ;)
basszero