When conversing with a Subversion developer, you might very likely hear reference to the term ancestry. This word is used to describe the relationship between two objects in a repository: if they’re related to each other, one object is said to be an ancestor of the other.
For example, suppose you commit revision 100, which includes a change to a file foo.c. Then foo.c@99 is an “ancestor” of foo.c@100. On the other hand, suppose you commit the deletion of foo.c in revision 101, and then you add a new file by the same name in revision 102. In this case, foo.c@99 and foo.c@102 may appear to be related (they have the same path), but in fact they are completely different objects in the repository. They share no history or “ancestry.”
The reason for bringing this up is to point out an important difference between svn diff and svn merge. The former command ignores ancestry, whereas the latter command is quite sensitive to it. For example, if you asked svn diff to compare revisions 99 and 102 of foo.c, you would see line-based diffs; the diff command is blindly comparing two paths. But if you asked svn merge to compare the same two objects, it would notice that they’re unrelated and first attempt to delete the old file, then add the new file; the output would indicate a deletion followed by an add:
D foo.c A foo.c
Most merges involve comparing trees that are ancestrally related to one another; therefore, svn merge defaults to this behavior. Occasionally, however, ...