But there are presciptions to avoid most possible unpleasantess:
- use as many simple text files as you possibly can: Subversion loves source files
- don't assign people to work on the same file
no seriously, and if you have too much in one file; just fix it - don't mess around with the files: keep the changes lightwieght and team-friendly
- some assets are inherently not good stable files suitable for parallel development:
visual studio solution files are a good example - solutions are isolate pre- and post- builds steps into separate script files; use external properties files
resist the temptation to store vast amounts of critical data in single gargantuan XML files
break up the monster files as much as you can
some files can acquire helpful changes from their IDEs: look into redacting the changes into the bare minimum changes needed for that change set; you will thank yourself when you have to review them later...
So, don't fear the merge conflict, and remember the end game is a development process where the maximum amount of development work is done with the minimum of hindrance.
So when a merge conflict does happen remember that may mean there is some more work to be done on the process and you have the opportunity to learn how to further improve the process.
