I know there's the sync merge which copies over the next set of changes from trunk. According to the docs, this is how the sync merge works:
Subversion will locate all the changes on 'trunk' that have not yet been merged into the 'feature' branch. In this case that is a single range, r100:200. In the diagram above, L marks the left side (trunk@100) and R marks the right side (trunk@200) of the merge source. The difference between L and R will be applied to the target working copy path.
It keeps track of what has and hasn't been merged into the feature branch using the mergeinfo. There's also the reintegrate merge which is described as:
The feature branch was last synced with trunk up to revision X. So the difference between trunk@X and feature@HEAD contains the complete set of changes that implement the feature, and no other changes. These changes are applied to trunk.
Both of these sound like two-way merges, which seems a lot less robust than a three-way merge like in git.
Edit: So, it looks like SVN does do 3-way merges, but the descriptions of sync and reintegrate merges above (and those found from some other sites) still sound like 2-way merges. If, and how, is this different from what git does with its merge? This post suggests that 3-way merges are pretty much the same across multiple VCS, and that it's how merges are tracked that makes the difference. So does that mean that SVN only chooses its base tree differently than git does?