Strategies for push/merge problem?

[Adrian Buehlmann]

On 14.07.2008 12:24, Roman Kennke wrote:
> 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).

You should do a *local* clone, which is fast because it uses hardlinks
(this even works on NTFS for Windows, provided you keep everything on
the same volume).

Have a clean copy of the central repo on each developer's harddisk
and always clone that (create the clean copy repo with clone -U, because
you won't need to populate it's working dir).

A clean copy means: never push or commit into that clean copy repo. Only
pull from your central one. And keep it, so you have to clone it only
once over the wire, and then always pull.

> 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.