We are deploying and upkeeping web-sites to different customers. Normally we wait for newest changes to stabilize, then tag subversion version as release, and install than version to customer. Then we receive support requests, and sometimes are forced to make quick bugfixes between releases. I find it troublesome to upkeep these bugfixes in branches, and wonder why not store them as "local changes" in some "Release X.Y"-folder (on build-machine)? Can this work, or is branching the only way?
Reasons for this change are:
it seems much easier to use WinMerge-utility for merging newest bugfixes into some "Release X.Y"-folder, than using tortoise-svn's "branch integration". WinMerge offers you much finer control over which changes to merge and which not (on file-basis, not commit-basis).
when keeping bugfixes as "local changes" you have three-way comparison: in "Check for modifications" you can see all the bugfixes in current release, and with WinMerge you can see all the newest trunk-changes (if compare "Release X.Y" with "trunk"-folder)
also it seems over-obsessive to keep everything in SVN. IMO SVN should serve the user and not the other way around.
also branch re-integration never merges only those files that have actually changed. It takes along whole bunch of unnecessary files, which make it difficult to track anything in SVN-log.