SVN patch workflow outline is the following:

1. create directories for copy destinations, patches, additions
2. copy stuff
3. patch stuff
4. add stuff
5. delete stuff
6. ...

The issue comes if directories are moved, e.g. refactoring of packages in Java. The premature creation in step 1 will result in erroneous directory structure due to the behavior of svn cp:

From: http://kera.name/articles/2012/08/why-caution-is-advised-when-svn-copying-directories/

I did a bit of research in the list archive, and came across this snippet,
posted by someone basically saying this was reasonable behaviour because
that's how *nix does it:

cp path/A path/B --> if path/B doesn't exist, creates path/B

if path/B does    exist, creates path/B/A

I case of directory move src/com/myname/p1 -> src/com/myname/p2, the above steps will produce this:

1. create src/com/myname/p2
2. svn cp src/com/myname/p1 src/com/myname/p2 (which results src/com/myname/p2/p1 because p2 already exists at the destination)

Proposed process:

1. collect directory and file copies in different collections
2. execute dir copies with svn cp --parents $src $dst
3. create dirs for file copies, patches, additions
4. execute file copies with same routine as the dirs
5. ...
6. add the --force flag to svn add to avoid false warnings that a given path is already under version control

I already have implementation for this.

References:
http://svn.haxx.se/users/archive-2007-04/1035.shtml
http://kera.name/articles/2012/08/why-caution-is-advised-when-svn-copying-directories/