Thanks for your answer but I think that my question was not clear enough.

I was talking about merge conflict detection... in source code. Often detected with a tool like git, mercurial, subversion, etc.

I'm a Linux kernel maintainer. Conflicts happen, but git makes the resolution straightforward, and can even try different merge strategies (git merge -X "ours"/"octopus"/etc). I wouldn't ever describe it as having been "merge hell". Maybe if it were a different SCM.

Linux has the "linux-next" tree, which merges feature branches together every night; Stephen Rothwell fixes up context conflicts in that tree which saves a lot of time, and the e-mails he generates also function as a notification that the code you're working with has conficts.

Having a nightly merge of all feature branches seems like the right kind of granularity of notification to me.

We get them regularly, maybe a couple a week. But for the most part you know what you are getting into. It usually comes up in code review that there's going to be a problem.

What I don't get though is how a realtime notification would help me. If my editor started flashing that I was in conflict, what would I do differently?

If you are notified in realtime, the merge conflict will be based on approximatively 1 line. It's easier to resolve it.

Suppose the "developer 1" working on a big feature during two weeks and a "developer 2" working on another big feature. If you detect the merge conflict at the end of the sprint, it can be difficult to resolve. Don't you think ?

Maybe the nature of our conflicts is different. Resolving things at the end is rarely that big of a hassle for us. I'd rather do it all at once after I'm done the work than interrupt my train of thought to fix it at the time.

Ok great. Thanks for your comments. Can I ask you how much developers (approximatively) work on your company ?

On my team, 6. On another team, 20ish.

Small team working on fairly big systems - we rarely have any merge conflicts due to the way we divide work up.

They can be a pain in the arse when something has gone wrong though - but it's not really something we spend a lot of time worrying about. If it happens we just deal with it.

Small team (~10) of developers: I rarely encounter merge conflicts due to our method of doling out tasks. We generally try to group tasks together based on similarities, and our codebase is very modular.

Great. Thanks for this comment.

Small team manager here -- not often at all. Most people are working on different components simultaneously so conflicts rarely arise.

Yes. I'm pretty sure that if you have a perfect organization in your team work, there's no need to have a tool like that.

Personally, I already create a merge conflict... alone :-) But it's because I am (was ? I hope...) not well organized.