Does Mercurial do a better job merging files when changesets are small?

Question

Let's say I have a development branch for some feature called "myDevelopmentBranch" and another branch "myOtherBranch" containing quite a lot of changes, some of will conflict with stuff from "myDevelopmentBranch". Will (potentially) the result of a merge from "myDevelopmentBranch" to "myOtherBranch" be different if I commit frequently than if I commit less often (e.g. several times a day versus one or two times per week)? I'm wondering about this as I would thing that it's easier for Mercurial (or any other VCS) to track changes in small chunks, hence doing a better job figuring out how to merge them.

Note! I'm aware of plenty of reasons to why one should commit frequently, this is just a technical question that I've been pondering about.

Answer 1

The merge resolves differences between the changed files as they stand at the tip of both branches (assuming you are merging the tips). So if you had...

• 1 changeset A1 on branch A that changes 500 lines, parent changeset Z
• 1 changeset B1 on branch B that changes 500 lines, parent changeset Z

...you would have the same merge experience compared with 50 changesets on each branch that change 10 lines each to produce the same final state of files in each branch as above.

However, in my experience what does make merging easier is not committing often but merging often. For example, merging changes of a stable branch into a development branch to keep the development branch based on the most recent stable version in smaller bites, rather than waiting until work on the development branch is done to update it with stable branch changes in one big bite. And in some cases, rebasing the stable branches changes instead of merging (depending on your DVCS workflow).