bug in "Undoing Changes" functionality of merge -c -N?

Hi.

I am running Subversion version 1.6.4 on a rhel5 system. Unfortunately, I
don't have admin access to my machine (it's a box in an academic
department), but colleagues have reproduced this behavior on newer versions
of Subversion.

The bug question I have is also posted at the following link, if it's
easier to read in that format:
http://stackoverflow.com/questions/11195483/conflict-when-attempting-undoing-changes-example-in-subversion

I was checking out Subversion functionality by attempting to recreate the
scenario given in the svnbook in the Branching and Merging chapter, in the
subsection "Undoing Changes", part of the Basic Merging section
(
http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.branchmerge.basicmerging.undo).

As I read it, that subsection claims that changes committed in the past can
be undone, leaving subsequent good commits unaffected, by running

svn merge -c -rN file:///path_to_repos/trunk

where rN is the resulting revision number of the commit that contained
errors to be removed.

In order to follow the example, in my working copy directory, I edited a
file testcode.py, adding one line per edit, and committing after each edit.
After several commits, the file read as follows:

----
this is my first import to trunk. r1.
this is my first commit, first edit of testcode.py. r2.
this is another edit of testcode.py. r3.
this is an edit of testcode.py. i'll get rid of this one. r4.
this is another edit of testcode.py. keeping it. r5.
yet another edit. keeping it. r6.
-----
The revision numbers in the repository match up to the lines in the file
such that in /trunk/testcode.py_at_rN, the last line of the file is the one
ending with rN. What I want to do is remove the line ending in r4, keeping
everything else before and after unchanged.
Following the example in the Undoing Changes section of the svnbook, I run
the command
svn merge -c -4 file:///path_to_repos/trunk
This creates a conflict (upon running that command, not on commit), whereby
the merge-left file contains everything up until line r4, and the
merge-right file contains everything up until line r3. In other words,
instead of removing a past change, the command seems to want to revert the
entire file back to either revision 3 or 4, removing changes in subsequent
revisions (5 and 6, in this case).
This appears not to be the way the merge command should behave, in this
case seeing as the Undoing Changes section of the svnbook has the
hypothetical user removing a commit from revision 303 with no conflict in
the merge -c command, and committing to revision 350.  If that example
holds, the command I ran should have produced a file with the line ending
in r4 removed and everything else unchanged.
This appears to be a bug, but if not, I'd appreciate some advice as to what
I'm doing incorrectly.
Thanks.
Nairn