Slime project considering Mercurial

Giorgos Keramidas keramida at
Fri Mar 7 06:40:06 CST 2008

On 2008-03-07 06:46, Paul Franz <theandromedan at> wrote:
>Giorgos Keramidas wrote:
>>On 2008-03-07 08:06, Peter Arrenbrecht <peter.arrenbrecht at> wrote:
>>>On Fri, Mar 7, 2008 at 5:28 AM, Paul Franz <theandromedan at> wrote:
>>>> I ask because I have a large ClearCase installation that I am
>>>> looking to move to Mercurial. But I want to make sure of two
>>>> things:
>>>> 1) It can clone the repository relatively quickly to our development team in
>>>> India (i.e. half a world away)
>>> If you have already created an hg version of your repo, I think using
>>>   hg init temp
>>>   hg -R temp in --bundle wiredata.bundle my-master-repo
>>> will create in wiredata.bundle the exact data stream that would go
>>> over the wire for the actual repo data.
>> Yes, indeed.  But this will create a bundle with *all* the commits in a
>> tree, including ones which have possibly been pushed out already to the
>> development team in India.
>> In newer versions of Mercurial, you can also do this without the extra
>> 'empty' workspace, by using the --all option of `hg bundle':
>>     % cd /ws/foo-project/releases/1.0-patches
>>     % hg bundle --all /var/tmp/wiredata.bundle
>> The initial `hg clone' of a repository may take a while, depending on
>> the link speed.  Subsequent `pull' operations are blazingly fast though.
>> I am pulling changes from the OpenSolaris source tree every week or so.
>> The current OpenSolaris source repository contains a little over 6,000
>> changesets for more than 40,000 files.  A `pull' completes on my home
>> DSL link in a few seconds (i.e. less than half a minute).
>> Creating a *full* clone over SSH to may take a while
>> though.
>> One of the easy ways to create *many* local clones in India is to create
>> a hierarchy of `workspaces'.  One can install a local `gate' in India,
>> and use the gate only for pulling changes from the official tree.  The
>> local India developers can clone the local gate instead of the remote
>> `master' tree.
> So the local India developers would pull from the local gate repository but
> push to the one in the US, correct?

Yes, that's one way to do it.

It may be worth considering a `pull based' model though.  Pulls scale
much better than several dozens of developers trying to push at the same

A pull based model can work with two `gates' at each remote site.  The
developers of site $FOO use gates foo-incoming and foo-outgoing.  A team
leader, local at site $FOO, is assigned the task of pulling from local
people into foo-outgoing, and then push once at the central gate in a
remote site.

This means that a `gatekeeper' is needed at each site.  The requirement
for a gatekeeper may or may not be helpful for the way you plan working.
It's just one of the ways you can use Mercurial to keep changes flowing
in a controlled manner to `upstream' gates.

More information about the Mercurial mailing list