Slime project considering Mercurial

Paul Franz theandromedan at
Fri Mar 7 13:36:14 CST 2008

Giorgos Keramidas wrote:
> On 2008-03-07 13:58, Paul Franz <theandromedan at> wrote:
>> Giorgos Keramidas wrote:
>>> On 2008-03-07 13:08, Paul Franz <theandromedan at> wrote:
>>>> Giorgos Keramidas wrote:
>>>>>> 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?
>>> Not necessarily.  One way to keep integrating developer workspaces is
>>> to let the gatekeeper do it.  Another one is to let the gatekeeper
>>> use `integration workspaces' and pull the gate into them.
>>> Then the gatekeeper can pull from any random number of developers
>>> into the integration workspace and simply refuse to merge changes
>>> which create multiple `heads', delegating the patch
>>> rebase/merge/integrate operation back to the developer who made the
>>> changes.
>> So the gatekeeper would try to pull from the developers repos into the
>> integration workspace and if a merge is required push back on the
>> developer to resolve the conflicts. But wouldn't this then cause a
>> slow down in getting the changes into the main repository? Meaning
>> that instead of the developer getting immediate feedback from pushing
>> directly to the main repository he would get feedback only when the
>> gatekeeper processes the next batch of changes.
> Yes, there will inevitably be at least some slowdown when a gatekeeper
> has to go through the integrate, reject, integrate, reject, integrate,
> reject cycle too many times.
> There are both advantages and disadvantages in practically *any*
> approach you can use.  You can always allow people to push directly to
> The Source Tree(TM), and then have to deal with breakage after the fact,
> or you can use a `stream' of workspaces where changes have to flow
> through and, invariably, wait a bit longer before a change hits The One
> True Tree.
Cool. I just wanted to make sure that I understood the approach. 
Definitely, something to consider for future process improvements. Thanks.

Paul Franz

More information about the Mercurial mailing list