There is an alternative to destroying and re-creating a branch after reintegration. To understand why it works you need to understand why the branch is initially unfit for further use after it has been reintegrated.
Let's assume you created your branch in revision A. While working on your branch, you created one or more revisions which made changes to the branch. Before reintegrating your branch into trunk, you made a final merge from trunk to your branch, and committed the result of this merge as revision B.
When reintegrating your branch into the trunk, you create a new revision X which changes the trunk. The changes made to trunk in this revision X are semantically equivalent to the changes you made to your branch between revisions A and B.
If you now try to merge outstanding changes from trunk to your branch, Subversion will consider changes made in revision X as eligible for being merged into the branch. However, since your branch already contains all the changes made in revision X, merging these changes can result in spurious conflicts! These conflicts are often tree conflicts, especially if renames were made on the branch or the trunk while the branch was in development.
So what can be done about this? We need to make sure that Subversion does not try to merge revision X into the branch. This can be done using the --record-only merge option, which was introduced in the section called "Blocking Changes".
To carry out the record-only merge, get a working copy of the branch which was just reintegrated in revision X, and merge just revision X from trunk into your branch, making sure to use the --record-only option.
This merge uses the cherry-picking merge syntax, which was introduced in the section called "Cherrypicking". Continuing with the running example from the section called "Reintegrating a Branch", where revision X was revision 391:
$ cd my-calc-branch
$ svn update
$ svn merge --record-only -c 391 ^/calc/trunk
$ svn commit -m "Block revision 391 from being merged into my-calc-branch."
Now your branch is ready to soak up changes from the trunk again. After another sync of your branch to the trunk, you can even reintegrate the branch a second time. If necessary, you can do another record-only merge to keep the branch alive. Rinse and repeat. It should now also be apparent why deleting the branch and re-creating it has the same effect as doing the above record-only merge. Because revision X is part of the natural history of the newly created branch, Subversion will never attempt to merge revision X into the branch, avoiding spurious conflicts.