Automated merging isn't perfect. Just because there isn't a line-edit conflict doesn't mean there isn't a syntactic conflict, and that doesn't mean there isn't a semantic conflict.
Does anyone have strategies for authoring low-conflict changes? Is this something that falls out of TDD or other approaches (Certainly TDD will help catch them, but does it actually prevent)?
First of all, your code base should be modular. Second, what you need is communication with the rest of your team. Everybody should know who is working on what. If there is a change in the internal API, it should be made clear to the whole team.
Also, before commiting, always fetch the last version, and if complex merging is needed, do it locally.
This is really a human problem, not a technical one. Source control doesn't replace proper communication channels. Your Project Manager should be on top of every changes, and he should realize when a change will span several people.
Also, common sence is needed. :)
Unit testing is of course a big help to catch the most elusive bugs that can come up when merging.
Talk to your fellow developers, and try to avoid sychronous editing of the same block of code wherever possible. Having a well-modularised architecture (small classes, decoupled functionality) makes this possible almost all the time.
If we ever do have a clash, we often resolve it by one of us switching to writing unit tests for untested code for a few minutes.
The best bet is to design your code such that it is unlikely that two developers will have to work on the same file at the same time. This means lots of small source files, rather than several giant ones. You should also modularise the binaries, breaking them up into a number of small libraries with minimal dependencies between the modules.
I've always found that the smaller my commits, the less likely they are to have merge conflicts. The folks who have big problems always seem to go off for days and work on things, then try to merge them all at once.
Right now I'm working on a 2 man team where we are right in the same codebase all the time. We each work in a personal branch and then integrate to a shared branch whenever we have something working. That's usually several times a day. We almost never have merge conflicts, and when we do they're pretty trivial.
So... get the latest code from the repository frequently. Work in your own branch, so you can commit your changes and merge other folks' work without affecting the rest of the team. Then push your own code up to the shared branch as frequently as possible so the changes will be as small as possible.
Also, talk to your team. If you know someone else is working in a specific file, you might want to wait until they get their work in before you jump in. Sometimes you can't help it, but communication at least lets you plan for a complicated merge rather than being surprised.
Classes that violate the single responsiblity principle are the hardest to merge. Finding a class that was difficult to merge probably is a sign that it needs to be refactored, probably in the direction of more parts.