How can you be confident that Subversion's automatic merges don't introduce logical conflicts?

svn update does automatic merges when it thinks it can. Shouldn't there be a pre-requisite or something? If you work in an organization where unit/regressi开发者_开发知识库on tests are mainly during QA testing, how on earth can anyone be confident that the merge did not create an insidious bug?

If you work in an organization where unit/regression tests are mainly during QA testing how on earth can anyone be confident that the merge did not create an insidious bug ?

You should review your changes right before you commit them. Whether you svn updated the base revision a few time while you were working shouldn't matter, the final changes are always against the latest version in the repository and that is what you should review.

More importantly: how can you be sure that any commit doesn't horribly break everything if you don't run tests before your commit? Developers should at least run and maintain the unit tests.

(Mind you, there are other reasons why merges by svn update can be a pain: if you get conflicts that are difficult to resolve, it's sometimes a bit too easy to get in a situation were you can no longer salvage your local changes. But that's another story, as forcing conflicts would just make the problem worse...)

In my experience conflcts hapen more often than the documentation says. Most are easy to solve but they must be solved.