Slime project considering Mercurial

Giorgos Keramidas keramida at ceid.upatras.gr
Fri Mar 7 13:05:39 CST 2008


On 2008-03-07 13:58, Paul Franz <theandromedan at gmail.com> wrote:
>Giorgos Keramidas wrote:
>>On 2008-03-07 13:08, Paul Franz <theandromedan at gmail.com> 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.



More information about the Mercurial mailing list