>>>>> "John" == John Beck <jbeck at eng.sun.com> writes:
Gary> 4) If I reference the parent via ssh I'm prompted for my id_dsa
Gary> passphrase. If I ssh to a SWAN machine I'm prompted for my id_rsa
Gary> passphrase.
Gary> Why the difference?
John> Don't know; someone else (Dave? Mark?) might.
Gary, what user are you using when you say "reference the parent via
ssh"? Is it the onhg user or yourself?
Gary> Why must I continually iterate pulls, updates, merges, commits,
Gary> recommits, pushes until I sneak in before someone else?
John> That is the Hg design model AFAIK.
This is something I've been nervous about for quite some time, but we
won't know how much of a problem it is in practice short of deploying
and seeing what happens.
I think the Mercurial design model is geared more towards pulls than
pushes. We went with a push model for a couple reasons: it's closer to
our Teamware-based workflow, and (more important) it forces individual
developers (rather than the gatekeeper) to deal with conflicting
changes.
The topic of how well a push model scales came up on the Mercurial users
list a couple weeks ago. Here's a particularly relevant quote:
> There's also a merge problem: the person best equipped to merge
> real conflicts are the developers who changed the code, not the
> single person whose job it is to pull. ("hey Fred and Bob, I don't
> understand these 2 conflicting changes, can you please come by my
> cube and tell me how I should fix it?")
That's one way to do it. Another is "hey Fred and Bob, your code
doesn't merge cleanly automatically, moving on, tell me when you've
sorted it out." There's a guy I know named Linus who does precisely
this for 50+ people every morning after breakfast. In the next
couple weeks, he'll probably merge on the order of 8000 changesets
from 1000 contributors. It works.
I'm not advocating changing to a pull model, and I'm not even convinced
that the Linux example applies directly to ON. But if we do run into
scaling problems with people trying to push, and we can't deal with it
with tools improvements, we could look at whether we could make a pull
model work.
mike
