The basic design of the working copy has two rules: (1) edit files as you please, and (2) use a Subversion client to make any tree-changes (add, delete, move, copy). If these rules are followed, the client can sucessfully manage the working copy. If renames or other rearrangements happen outside of Subversion, then the UI has been violated and the working copy might be broken. The client cannot guess what happened.
People sometimes run into this problem because they want to make version control "transparent". They trick users into using a working copy, then have a script run later that tries to guess what happened and run appropriate client commands. Unfortunately, this technique only goes a short distance; svn status will show missing items and unversioned items, which the script can then automatically svn rm or svn add. But if a move or copy has happened, you're out of luck. Even if the script has a foolproof way to detect these things, svn mv and svn cp can't operate after the action has already occurred.
In summary, a working copy is wholly under Subversion's control, and Subversion wasn't designed to be transparent. If you're looking for transparency, you can set up an Apache server and use the "SVNAutoversioning" feature described in Appendix C of the Subversion book. This allows users to mount the repository as a network disk, and any changes made to the volume cause automatic commits on the server.