Strategies for push/merge problem?

[Roman Kennke]

Hi there,

I'm doing a transition from CVS to Mercurial in my work place now. As
expected, I get a lot of complaints about the one big problem with
Mercurial, which is the push/merge conflict. When using Mercurial in a
centralized way (I think many groups do this: they use a centralized
repository as THE repository to pull from, and use HG in a distributed
fashion to exchange stuff between developers), the push/merge thing
really becomes a big pain. As soon as there are more than 1 developers
working on the code, you basically have to always do the push (fail) &
pull & merge & commit & push (again) dance, which is a major pain. Ok, I
probably can convince people that this makes sense, and I can show them
the fetch tool, but it really gets complicated when people try to do
this with outstanding changes. Let me give you an example:

Lately a developer in my team who is developing on some code needed to
get in a quick fix for a problem that was biting everybody else. It was
a one liner. So he quickly did it, committed it and tried to push. Which
failed, because somebody else has pushed something in the meantime since
he pulled last time. Ok, no problem. Trying hg fetch: also fails,
because he had outstanding changes in his working directory. Trying
manually: seems to work until the merge step, which also complains when
you have outstanding changes. What followed was a quite difficult
procedure, creating a patch out of the changes, reverting things,
merging, committing, re-patching, pushing, etc. It was a mess. And all
this for a one-liner. I think my coworker was very annoyed and this
really doesn't help when trying to adopt mercurial. Most importantly, it
sounds very strange when I tell people that HG is made for scalability,
but with this kind of problem it really doesn't scale at all.

So my question is, are there any recommended strategies to solve these
kind of problems? Is there something I can tell people how to avoid such
situations? Is it possible to make all this easier? My solutions so far
are:
- Pull BEFORE committing, and push immediately. Brings the chance of a
merge conflict down to almost zero (depending on the size of the team).
- Try to always have a clean workspace without uncommitted changes
(impossible I think, but you can try).
- Use fetch when possible.
- Use patch queues to temporarily make uncommitted changes disappear
(stupid workaround, really. and needs MQ to be enabled).
- Use clones for each separate work. This is kind of difficult, take the
one-liner as example. Cloning a whole repo takes  ~5 minutes in our case
(lots of history). So people tend to quickly hack it in an already
cloned repository and run into the above situation.
- Use an additional in/out repository between the master and work
repository. Adds more overhead, but helps to solve the problem above.

Also: I know that the centralized approach is not the most HG-ish way to
work with HG. But I also think that a lot of people are using it that
way, and it shouldn't be so difficult to do. One nice thing about HG is
its flexibility, but this needs to be easier.

I really would like to hear your opinions and experiences. What should I
tell my co-workers?

Also: I still think that having a server-side automatic merge feature
(as discussed in an earlier thread) would be VERY helpful, maybe as an
additional command line switch for push, or even as an extension.

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