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

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 开发者_如何学Pythonan 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?

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.

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

It is common as you really do need to get your repos in a consistent state. One thing that speeds it up is instead of

hg pull; hg update

use fetch

hg fetch

This will intelligently do a pull and than either an update or a merge. It comes with mercurial so it's basically a matter of editing your .hgrc to add a line like so:

[extensions]
hgext.fetch=

If the merge goes cleanly you won't even notice it happening. That was a big help in my workflow.