Merge on push?

[Roman Kennke]

Hi there,

One of the most frequent complaints about Mercurial (probably even _the_
most frequent complaint) is that it is so difficult to push stuff to
remote repositories. While Mercurial is a distributed RCS, I think that
the majority of projects still have a central repository that serves as
a the basis for releases etc. At my workplace, we tend to do work using
a mixed approach: we have one central repository, but developers pull
stuff from each other anyway, i.e. in order to exchange patches that
can't go into the master at this point, but need testing in a different
context, etc.

I think pushing to a central repository is a very important action, and
I also think that it is unnecessarily complicated in Mercurial. The
current situation is that when a developer tries to push, in almost all
cases it aborts and he needs to pull && merge && commit and then push
again (don't forget to update at some point too). I know, hg fetch can
make all this a little easier, but still, it is additional overhead at
the side of the developer. The worst thing is, that it is possible that
after the fetch sequence, the push can fail again, when another
developer managed to push something in between. This isn't much of a
problem in projects with few developers or when developers tend not to
push very often. However, for large scale projects with a push-often
policy, this is really bad.

I know that there are ways around this using different workflows, for
example, large projects could split up the central repository into a
hierarchy of group repositories (like in OpenJDK), or it could use a
pull-only approach, where a release maintainer pulls the patches he
wants in the master repo from the developer repositories. But this is
not my point, my point is that when a group _wants_ to use the push
approach, then it makes no sense to make that so hard.

I'd like to propose an extension to the push command. I imagine an
option --merge and maybe a configuration option for use in ~/.hgrc which
makes push try a merge on the remote side if necessary. hg push --merge
would then try to perform a non-interactive merge and commit on the
remote repository, when the push would create an additional head. This
should fail when the changes touch files that have been touched by other
changesets since their 'branch-point'. This is more or less the
behaviour of more traditional RCSes. I know, there is a chance that this
results in a broken tree even when there are no overlapping changes, but
experience with more traditional RCSes (CVS and Subversion, maybe other
DRCSes, dunno about them) shows that such cases are very rare in a
reasonable structured project.

Does that make any sense? Or is there something I just don't see from my
POV? I think Mercurial is otherwise a very scalable and usable DRCS, but
this single point is a real pain, and truly hinders adoption (at least,
I'm having a hard time defending HG among my coworkers and developer
friends at a couple of projects).

Cheers, 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-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt