Slime project considering Mercurial

Paul Franz theandromedan at gmail.com
Fri Mar 7 12:08:30 CST 2008



Giorgos Keramidas wrote:
> 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.
>
>   

I assume then that the gatekeeper would be assigned integration/merge 
conflict resolution duty, correct?

Paul Franz


More information about the Mercurial mailing list