SVN started to try to be clever with merges by tracking past merges between copies of files. This required tracking a lot of new information for each file. The

SVN started to try to be clever with merges by tracking past merges between copies of files. This required tracking a lot of new information for each file. The developers used a combination of implicitly inferred merge history and annotations stored in SVN properties on each file for that. Combined with the fact that merge and commit were two separate steps in the workflow with manual conflict resolution in-between, this lead to sometimes severe usability issues. The merge would adjust the mergeinfo properties along with the files. Users would sometimes go and do svn revert on some of those files as part of conflict resolution. This would also silently reset the mergeinfo properties that were just updated. The current merge would still work out OK. But future merges involving the current branch or its descendants would get horribly mangled because SVN ends up applying sets of changes that are out of sync with the actual state of the files involved. That's part of what gave SVN its bad reputation.