Strategies for push/merge problem?

Sean Kelley sean.v.kelley at gmail.com
Sun Jul 20 15:53:51 CDT 2008


On Sun, Jul 20, 2008 at 10:34 AM, Douglas Philips <dgou at mac.com> wrote:
> On or about 2008 Jul 20, at 11:10 AM, Sean Russell indited:
>> I'm not sure that I agree with the proposition that the "correct"
>> way to use a
>> distributed version control system is through a pulling model.
>> Again, I
>> assert that it inserts a single point of failure, a bottle neck,
>> into the
>> workflow.
>
> I think you are missing a "not" in  your sentence there. A CVS-like
> "one and only one true central location" is the bottle-neck, single
> point of failure. With the pull model, the pullers can be anywhere on
> the network(s) that can reach the pullees. It is only if you insist on
> a well-known "central location" for the pullers results that you have
> a single point of failure, and then that is because you've made a
> social/operational decision to mimic another model.

 The real bottleneck in my experience is requiring one person to
handle all pulls to a 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.

>> 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.  I balance that with SQA and nightly
builds.

>
>> Well, I don't place too much value on the argument for not
>> interrupting the
>> SOP.  To me, the push model is simply more egalitarian, and scales
>> better,
>> and I don't see any reason why it is fundamentally incompatible with
>> HG.
>
> The main problem with the SOP is the Commit==Push mentality that DVCSs
> provide relief from, since DVCSs also have had to solve the "branch
> merging is painful" problem to get there.

I think Bzr has some very nice ways of handling this through SVN like
commits used in conjunction with an ability to crate feature branches
for your development and offline commits.

Sean

>
> But no, you don't have to step away from the push model if you don't
> want to, but you will have to decide if you want multiple heads merged
> later, or if you want a "fetch/push" model. The beauty of using a push
> model with HG is that is shows how broken the push model with CVS was,
> because suddenly now folks have to deal with the fact that changes to
> files that they didn't change aren't invisible. My group at work is
> still adapting to that, although we had already put in place some
> procedures with our CVS based workflow to address CVS weakness in that
> regard.
>
>        --Doug
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>


More information about the Mercurial mailing list