Slime project considering Mercurial

[Giorgos Keramidas]

On 2008-03-07 06:46, Paul Franz <theandromedan at gmail.com> wrote:
>Giorgos Keramidas wrote:
>>On 2008-03-07 08:06, Peter Arrenbrecht <peter.arrenbrecht at gmail.com> wrote:
>>>On Fri, Mar 7, 2008 at 5:28 AM, Paul Franz <theandromedan at gmail.com> 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 hg.opensolaris.org 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
time.

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.