Hopefully others struggling with this problem will now Google this blog and find your solutions!

* make a branch of trunk (for example to branches/deprecated_trunk_20080121)
* delete the trunk-directory
* make a branch of the stable release tag into trunk (for example from tags/1.0 to trunk)

In my opinion you try to achieve three different things in one action. Your end result is perhaps workable, the logging history will be a bit confusing. I would do it as follows.

First the customer wants you to create a change on code that is in production (According the conventions of subversion the production code is tagged). In subversion it is not done to change a tag, thus I would create a branch. This is the place where you can adapt the code for the new situation.

Secondly the desired change is already done in the trunk.. With a bit of luck the wanted change can be identified in one or two commit steps. I would merge these steps into the newly created branch. This process is called creating a back-patch. When I commit the back-patch I would note the revision numbers from the trunk, including the comment on the original change.

At last it is decided that the new development will not be done on the trunk anymore. The trunk becomes obsolete. New functionality will be added tot the branch. Because in subversion the trunk is always the latest and greatest code I would rename the trunk to a branch name for example trunk_version_discontinued. I would rename the new branch to trunk.

The end result is the same as with your actions, but the logging history reflects now better what was done. And in case you need more changes that can be found in the former trunk you can easily merge them again.

Success with the remainder of the project