Rename fun and Philip's patch

After checking out Philip's patch some more I've noticed the following
things:
* The svn_fs_rename logic always works on files (vs. lazy copies, and
nested lazy copies and ignoring the change table issues)
* The svn_fs_rename logic can create situations in which NodeRevision PK
violations can occur for directories.
e.g:
      cp /A /B -- B is (A.1.Txn1)
      mv /A /B/A -- /B/A is (A.0.Txn0), while /B is (A.1.Txn2)
 
Any additional change under /B/A will immediately cause a PK violation.
This case is the easier case to handle. choose_copy_id can be made to
detect that /B/A isn't a lazy change by noticing that the last
encountered branch point on the current path (/B) has the same NodeID
(A) as the NodeRevision we want to make mutable (A.0.Txn0) and we can
issue a new CopyID so that /B/A gets (A.2.TxnN).
 
Here's another fun one:
       create /A/foo as a directory (Foo.0.Txn1)
       cp /A /B (B.1.Txn2)
       add /A/foo/bar (bar.0.Txn3), (Foo.0.Txn3)
       begin Txn4
       mv /A/foo /B/foo2 -- both are (Foo.0.Txn3)
       edit /B/foo/blah (blah.1.Txn4), (Foo.1.Txn4)
       edit /B/foo2/bar (bar.1.Txn4), (Foo.1.Txn4) -- badness occurs on
this line.
       commit Txn4
When /B/foo2 is made mutable again, a PK violation will occcur because
the new node revision for /B/foo2 will be (foo.1.Txn4).
 
This one is a tad trickier to handle and nothing is coming immediately
to mind to easily and cheaply handle this one. (Aside from completly
disallowing it altogether.) I'm still pondering this one though, just
wanted to send this note out and see if anybody else had any other
bright ideas.
 
* Use of svn_fs_compare_ids in the test case: This function always
annoys me, it falls back to calling svn_fs_check_related if the ids
aren't exactly equal. Needless to say, this test case shouldn't be this
fuzzy.
 
FYI,
Bill

----
Do you want a dangerous fugitive staying in your flat?
No.
Well, don't upset him and he'll be a nice fugitive staying in your flat.