Strategies for push/merge problem?

Roman Kennke roman.kennke at aicas.com
Tue Jul 15 14:31:43 CDT 2008


Hi Matt,

> On Tue, 2008-07-15 at 07:51 +0200, Peter Arrenbrecht wrote:
> > We all heard that Matt is not interested in the push approach. Fair
> > enough. So the question is, do sufficiently motivated people want to
> > take this into their own hands? I think it's not that hard to do as a
> > client and server extension, which could alleviate both the merge race
> > and the mergeful history problems. But, of course, a legimitate
> > question is if it stands a chance of getting official extension status
> > (Matt?).
> 
> Doing merging on the server is not a good idea. Setting aside all the
> security and resource usage and complexity issues, it means that the
> resulting commit is not something anyone has ever even seen, let alone
> tested. And now it's in your history permanently. Who's name goes on
> that commit?

Of course you are absolutely correct. But you have to keep in mind, that
transitioning from one SCM to another (HG in this case) is much less a
technological problem than a social one. What you describe above is
exactly the behaviour of CVS and Subversion and probably some other
SCMs. A generation of developers has learned to use these tools and have
accepted this kind of behaviour. Most of them don't even know that it is
broken. We need to teach them, yeah. But we will not teach them if we
tell them, whatever you learned in all those years is wrong, my solution
is the only correct thing to do. This will only have the effect that
people get turned off by you and will defend.

And it has to be said, the way CVS and Subversion handles these things
has one big advantage: it is perfect for lazy people. All the
technological advantages of Mercurial are meaningless to many people,
when they have to perform N steps (with N>1, where 1 is the number of
steps this takes in those other systems) to get patches into the team
development repository. It happened to me lately 'Hey, WTF is this? I
need to do 6 steps to get a oneliner pushed (push (fail), pull, update,
merge, commit, push (again)), and this is the ideal case when I don't
have the workspace cluttered with uncommitted changes (another bad
behaviour encouraged by CVS...)'. On a technological level, everybody in
my team agreed the HG is the way to go, but on a social level, it just
doesn't fly yet.

I don't think that HG should try to enforce your (and my) point of view
on everybody. I was telling people that one of the great strengths of HG
is its flexibility, people can use HG in whatever way they want. But it
turns out that when using it in a classical centralized way, people get
punished badly. I know that all the behaviour people carry over from CVS
is basically broken, and it needs to be changed. I'm only thinking that
regarding the push/merge thing, HG makes it unnecessarily hard for
people to adopt.

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt




More information about the Mercurial mailing list