Strategies for push/merge problem?

Alpár Jüttner alpar at cs.elte.hu
Sun Jul 20 16:22:36 CDT 2008


Hi,

>  The real bottleneck in my experience is requiring one person to
> handle all pulls to a repo.

Because you probably overlook the fact that using DVCS you typically
will not have a single central repo with a single person maintaining it.
Nobody is forced to use a single repo and more importantly, people don't
have to wait with using a commit until it gets into some "main"
repository.

For example people can exchange changesets directly and every team can
have an own "sub-main" repo, where they collects their (somewhat review)
commits and which is regularly pulled by a maintainer of a "more main"
repo.

>   That has an unacceptable impact on
> development and time to market not to mention resources.  Again, the
> analogy on the net with onesy twosy repos per project does not match
> the needs where you have more than one hundred developers and more
> than one hundred repos.

Using mercurial every checkout/clone is a repo, thus you cannot avoid
having a lot. In fact, this is a decided bonus, not a root of problem.

> 
> >> That one developer who is pulling from everybody's contribution
> >> tree has to be intimately familiar with the entire project, and with
> >> every
> >> contribution.  This is fine if you're Linus, and you own the project
> >> back to
> >> its inception; this is less probable in a corporation where there is
> >> turn-over.  It also exposes a lack of trust in developers to be
> >> competent and
> >> merge their own changes.
> >
> > Hardly. Did you read Matt's message on the scalability with the
> > example of incrementing a counter?
> > The Kernel model is exactly the opposite of what you describe. Changes
> > are -not- pulled if they cause a merge issue, the developer has to do
> > the merge before the changes will even be considered.
> 
> In my experience, no one 'owns' a particular repo.  No one gates any
> pushing to a repo.  To do so in my corporate environment is a disaster
> when you attempt to scale. 

Probably yes, assuming that you attempt to do the whole process of
managing the source code exactly in the same way as you did it with
CVS/SVN.

Best regards,
Alpar



More information about the Mercurial mailing list