However, your suggestion for automatic commits to SVN based on an iWatch trigger might do the trick! It would certainly take care of versioning; the in-progress code could be always stored in a fork as not to pollute the trunk. In the past I had a reverse setup where I did a commit to SVN (or at that time to CVS) on every change/save, and a script then updated a working copy in the web directory. But that was a pain to work with as there was always a 4-6 second delay before the change would be reflected in the web folder and so in the browser refresh. If commits to SVN would be triggered by an iWatch event, it would occur independently from server side debugging (I'll use this this with zend server) and browser update. The only consideration would be configuration files and such which I would ultimately not want to commit to the trunk, but perhaps they could be pruned during the fork merge process.
I'll give this a try, and update this thread later. More ideas/thoughts are of course welcome! :)