Is constant merging with Mercurial common practice? Something wrong with this workflow?

Question

My company is switching to Mercurial, and we're coming from Subversion.

We're noticing that we're having to do a LOT of merging in our workflow. For instance, if I change a file, commit, pull, update, push, and then my co-worker changes a file, commits, pulls, and updates, he gets a "crosses branches" error and has to do an hg merge. We're having to do this pretty much every single time we want to push to our central repository.

Is something wrong with our workflow?? It seems wrong that in our history for a given file there are going to be a ton of history entries that say "Merging with [changeset id]" "Merging with [changset id]."

Is this just the way it is? Or are we doing something wrong?

Answer 1

There's nothing wrong with this. The vast majority of merges should be automatic. You did create two heads when you both made changes stemming from the same revision and going in divergent directions - your changes might or might not conflict.

If you want to eliminate the "merge" changesets (which aren't actually a problem), you can change/pull/rebase/commit/push instead of change/commit/pull/merge/commit. In other words, before committing your changes, rebase them to the new tip.

Answer 2

If the merges are being executed without manual merge resolution, then I would say mercurial and your workflow are behaving as designed.