Mercurial: devs work on separate folders, why do they have to merge all the time

Question

I have four devs working in four separate source folders in a mercurial repo. Why do they have to merge all the time and pollute the repo with merge changesets? It annoys them and it annoys me.

Is there a better way to do this?

Answer 1

Your development team are committing little and often; this is just what you want so you don't want to change that habit for the sake of a clean line of commits.

@Kevin has described using the rebase extension and I agree that can work fine. However, you'll also see all the work sequence of each developer squished together in a single line of commits. If you're working on a stable code base and just submitting quick single-commit fixes then that may be fine - if you have ongoing lines of development then you might not won't want to lose the continuity of a developer's commits.

Another option is to split your repository into smaller self-contained repositories.

If your developers are always working in 4 separate folders, perhaps the contents of these folders can be modularised and stored as separate Mercurial repositories. You could then have a separate master repository that brought all these smaller repositories together within the sub-repository framework.

Answer 2

Assuming the changes really don't conflict, you can use the rebase extension in lieu of merging.

First, put this in your .hgrc file:

[extensions]
rebase =

Now, instead of merging, just do hg rebase. It will "detach" your local changesets and move them to be descendants of the public tip. You can also pass various arguments to modify what gets rebased.

Again, this is not a good idea if your developers are going to encounter physical merge conflicts, or logical conflicts (e.g. Alice changed a feature in file A at the same time as Bob altered related functionality in file B). In those cases, you should probably use a real merge in order to properly represent the relevant history. hg rebase can be easily aborted if physical conflicts are encountered, but it's a good idea to check for logical conflicts by hand, since the extension cannot detect those automatically.

Answer 3

Mercurial is distributed, it means that if you have a central repository, every developer also has a private repository on his/her workstation, and also a working copy of course.

So now let's suppose that they make a change and commit it, i.e., to their private repository. When they want to hg push two things can happen:

• either they are the first one to push a new changeset on the central server, then no merge will be required, or
• either somebody else, starting from the same version, has committed and pushed before them. We can see that there is a fork here: from the same starting point Mercurial has two different directions, thus a merge is required, even if there is no conflict, because we do not want four different divergent contexts on the central server (which by the way is possible with Mercurial, they are called heads and you can force the push without merge, but you still have the divergence, no magic, and this is probably not what you want because you want to be able to checkout the sum of all the contributions..).

Now how to avoid performing merges is quite simple: you need to tell your developers to integrate others changes before committing their own changes:

$ hg pull
$ hg update
$ hg commit -m"..."
$ hg push

When the commit is made against the latest central version, no merge should be required. If they where working on the same code, after pull and update some running of tests would be required as well to ensure that what was working in isolation still works when other developers work have been integrated. Taking others contributions frequently and pushing our own changes also frequently is called continuous integration and ensures that integration issues are discovered quickly.

Hope it'll help.