3

I'm working on a larger project in a team of 5 developers and we're using Mercurial as VCS.

We all tend to work and commit locally until we deem a feature / fix ready to be pushed and then merge and push our changes. I usually push (and thus merge with remote) several times a day, as do most of the others.

This often leads to "merge clutter": multiple devs pull, merge and push changesets. The resulting history is not very pretty, and sometimes it looks like this:

merge clutter

I doubt one could isolate a specific changeset in that mess, or even figure out how / what it affected in what way (at least I shudder at the prospect).

If the merges were necessary, the above history would be fine I guess, but most of these merges could be avoided (safely) by rebasing, since every developer works on specific tasks that are more ore less isolated from the rest.

The actual question:

  • Is it "normal" that VCS histories look like the above? Should such histories be avoided?
  • How would one avoid such a history?

About the "avoid" part: Since the tasks we work on are somewhat isolated (Backend, Frontend, Web), we could split them into branches or maybe even separate repositories. The projects are not completely independent from each other though, so I suppose splitting into several repos causes more pain than gain. I'm not sure if named branches would be much better either, since then we constantly have 3+ branches there which would have to be merged ferquently into trunk.

Rebasing seems like an option, especially since many changesets are completely independent from each other – however this puts the burden of deciding whether to rebase or not on the developer. There may be conflicts and then one would have to merge after all. This may well lead to people not rebasing in the first place, so we're back to where we are now.

Right now I can't think of another option to make the history look cleaner. It may not be much of an issue now, but what happens when there are suddenly 20 developers? If the history is one big maze, then what's the point of it? I deem it hard to track the effects of a changeset if there are dozens of intersections.

enzi
  • 4,057
  • 3
  • 35
  • 53

3 Answers3

3

What you're looking at is, more or less, what's supposed to happen when you've got multiple developers all working on the same repository.

The only real way around it involves rewriting history, particularly if you've made local commits. You'd need to pull, rebase, then push.

Edit: There's one thing about your revision graph that strikes me. There's a lot of branching from branches and merging across these sub branches. It looks, well, chaotic. If your branching and merging is as chaotic as that appears, them perhaps your team could benefit from a more structured approach to branching and merging.

The "Successful Git Branching Model" that inspired git-flow can be applied to Mercurial repositories as well. hgflow is an extension that helps to implement it.

If that looks like too much structure then you can always find another way forward. However, it might be worth investing some thought in and bringing to the attention of your team.

See also: commit-pull-merge-push or pull-merge-commit-push?

Community
  • 1
  • 1
afrazier
  • 4,784
  • 2
  • 27
  • 30
  • Hmm so aside from rebasing, there's nothing we could do get a clearer history? Would separate branches help? I fear that, if we would create feature branches, we'd end up merging not often enough into trunk and get tons of conflicts per merge – or merge too frequently, in which case the situation wouldn't change from what we have now, only that the branches are actually named. Are there perhaps some tutorials / best practices on how large projects go about this? Or does their history look similar to the image above? – enzi Sep 18 '12 at 22:29
  • If you have more named branches, it's much easier to filter in tortoise hg. You could also look at hg-flow for inspiration. Naming branches but only gives you more context, but they're easier to close and selectively clone as well. – afrazier Sep 19 '12 at 00:29
  • @ Edit: It _is_ chaotic – thus my question. hgflow is definitely something I'll recommend when we start releasing stuff; at the moment, we're all working on the 'development' branch. I will encourage my colleagues to consider rebasing if they worked on some isolated stuff and also recommend the creation of feature branches for bigger tasks. Some of the branches will be named at least then. I'll accept this answer since it sums the situation up and also links to git-flow, which people looking at the question might find useful. – enzi Sep 24 '12 at 06:54
3

Yes, use rebase and avoid Noisy merges its safe (since hg-2.1) and simple.

You are a small team of 5 developers. All the merge above most probably happen because "I made some commit on part X at the same times than Bob worked on part Y". Those merges do not bring any useful information and nobody cares about using your micro branches independently.

Keeping branches in your history is useful when there is a good semantic for it, (eg: stable branch for bug fixes, default branch for new features) or when a changes took a long time to be mature and deserves to be merge with others. Other merges are just noise to me.

Since the introduction of phases (Mercurial 2.1), it is very safe to use rebase as (by default) Mercurial will allows you to rebase local changesets only. You new workflow may looks like:

  • clone
  • hack
  • commit
  • hack
  • commit
  • pull
  • rebase
  • test
  • push
Marmoute
  • 192
  • 1
  • 3
1

You're looking at too many levels of abstraction, then complaining that it looks too complex. There is an option to limit your view to the mainline of your branch. Use it. Only delve into the merged in branches if you have a specific need. It's better to have history available and unneeded than to destroy it with a rebase.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
  • The image above shows only the trunk, there are no other branches involved. Are you suggesting that we create several feature branches and merge them frequently, as I described in my question? – enzi Sep 18 '12 at 22:15
  • Your diagram shows no fewer than 9 branches. They may not be named, but every different colored line is a separate branch. You should be able to configure it to only show the blue branch on the left. If you tell me what GUI you're using I could help you find the setting. – Karl Bielefeldt Sep 18 '12 at 22:24
  • Ah, I see. I thought you were talking about actual named branches. I'm using tortoise hg most of the time (plus VisualHg inside Visual Studio). I was not aware that there was a setting for this. – enzi Sep 18 '12 at 22:32