Slime project considering Mercurial

[Paul Franz]

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.

Paul Franz