Geek Answers Handbook

Continuous merger with conventional Mercurial practice? Is there something wrong with this workflow?

My company is switching to Mercurial, and we came from Subversion.

We notice that we need to do a lot of merging in our workflow. For example, if I modify a file, commit, pull, update, click, and then my employee changes the file, commits, pulls and updates, he receives an error "crosses branches" and should perform hg merge. We need to do this almost every time we want to click on our central repository.

Is there something wrong with our workflow? It seems wrong that in our history for this file there will be a ton of history entries that say: "Merge with [changeet id]" "Merge with [changset id]".

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

+6
merge mercurial
source share
3 answers

There is nothing wrong. The vast majority of mergers should be automatic. You did the creation of two heads, when you both made changes that came from the same revision and went in different directions - your changes could or could not conflict.

If you want to exclude “merging” change sets (this is actually not a problem), you can change / pull / rebase / commit / push instead of changing / commit / pull / merge / commit. In other words, reinstall the new tip before making changes.

+4
source share

If mergers are performed without manually authorizing the merge, I would say that mercurial and your workflow behave as designed.

+1
source share

This is common, since you really need to get your repositories in a consistent state. One thing that speeds it up, instead

hg pull; hg update

use fetch

 hg fetch

It will be wise to do attraction, not renewal or merging. It comes with mercury, so basically it is a matter of editing your .hgrc to add a line like this:

 [extensions] hgext.fetch=

If the merger is clean, you won’t even notice that it will happen. This was a big help in my workflow.

+1
source share

More articles:


All Articles