Checksum mismatch after canceling conflict resolution

I've been spending some time this morning playing around with
interactive conflict resolution, and ran across this little gem:

hwright@spock:~/test/greek.wc$ svn up
Conflict discovered in 'iota'.
Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : h
  (p)ostpone - mark the conflict to be resolved later
  (d)iff - show all changes made to merged file
  (e)dit - change merged file in an editor
  (i)nteractive - prompt for each conflicting hunk
  (r)esolved - accept merged version of file
  (m)ine - accept my version of file
  (t)heirs - accept their version of file
  (l)aunch - use third-party tool to resolve conflict
  (h)elp - show this list

Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : d
--- .svn/text-base/iota.svn-base Fri Nov 2 09:35:14 2007
+++ .svn/tmp/tempfile.tmp Fri Nov 2 09:35:20 2007
@@ -1 +1,5 @@
-This is the file 'iota'.
+<<<<<<< .mine
+This is the file 'iota'. asdf
+=======
+This is the file 'iota'. 1234
+>>>>>>> .r2
Select: (p)ostpone, (d)iff, (e)dit, (r)esolved, (h)elp for more options
: subversion/svn/main.c:934: (apr_err=200015)
svn: Caught signal
hwright@spock:~/test/greek.wc$ svn up
At revision 2.
hwright@spock:~/test/greek.wc$ svn up -r1
subversion/libsvn_wc/update_editor.c:2032: (apr_err=155017)
svn: Checksum mismatch for '.svn/text-base/iota.svn-base'; expected:
'0a18339a4d1bddab170f4811a8ef6384', actual:
'2d18c5e57e84c5b8a5e9a6e13fa394dc'
hwright@spock:~/test/greek.wc$ ls
A iota
hwright@spock:~/test/greek.wc$ svn up -r0
D A
D iota
Updated to revision 0.

As a result of canceling the conflict resolver in operation, it appears
that some metadata in the wc wasn't updated correctly. I couldn't
update to r1, but I could update to r0 and then back to r1.

Is this intended behavior?

-Hyrum