When a branch is reintegrated to the trunk, is that branch effectively dead? Can you make modifications to the branch after the reintegration and merge those back into the trunk at a later date?
No the branch is still alive but, at that moment, is exactly the same as the trunk. If you keep developing on the branch, you are free to re-merge with the trunk later on.
You can merge from a branch to trunk, or trunk to a branch, as many times as you want.
When you do a merge, you specify the target. You can merge the differences of TreeA and TreeB to TreeC if you like. As Chris implies, your question doesn't really make that much sense. If you merge your branch into the trunk, the branch remains untouched. If the branch isn't needed afterwards, you could delete it.
You can keep on developing on the branch, the feature you will need is merge-tracking which is in Subversion 1.5, this means that additional merges from the branch only include new changes.
As everyone has already said it here: the branch isn't dead and commits to the branch can continue just fine.
Sometimes though you want to kill the branch after the merge. The only reliably solution is to delete the branch. The downside is that then it's harder to find the branch again if you wanted to have a look at it, say, for historical reasons. So, many people leave the "important" branches lying around and having an agreement of not changing them. I wish there was a way to mark a branch dead/readonly, thus ensuring nobody can commit to it until further notice.
Some advice on merging the changes back if someone makes changes the branch multiple times (pre 1.5): remember at which revision you did the merge! Either write the revision numbers down somewhere, or (which is easier) make a tag. (you can of course find it out later, but thats a pita)
Example:
you have a repository layout like this:
/your_project
/trunk
/branches
/tags
Lets say it is a web app and you have planned to make a release. You would create a tag, and from that (or from trunk) a branch in which you do the bugfixes
/your_project
/trunk
/branches
/1.0.0-bugfixes
/tags
/1.0.0
Doing it this way, you can integrate the new features in the trunk. All bugfixes would happen only withing the bugfix branch and before each relaese you make a tag of the current version (now from the bugfix branch).
Lets assume you did a fair amount of bugfixing and released those to the production server and you need one of those features desperately in the current trunk
/your_project
/trunk
/branches
/1.0.0-bugfixes
/tags
/1.0.0
/1.0.1
/1.0.2
You can now just integrate the changes between 1.0.0 and 1.0.2 in your trunk (assuming you are in your working copy)
svn merge http://rep/your_project/tag/1.0.0 http://rep/your_project/tag/1.0.2 .
This is what you should remember, you already merged the changes between 1.0.0 and 1.0.2 upon the trunk. Lets assume there are more changes in the current production release:
/your_project
/trunk
/branches
/1.0.0-bugfixes
/tags
/1.0.0
/1.0.1
/1.0.2
/1.0.3
/1.0.4
You are now ready to release the new version from trunk, but the last changes of your bugfixes are still missing:
svn merge http://rep/your_project/tag/1.0.2 http://rep/your_project/tag/1.0.4 .
Now you have all changes merged on your trunk, and you can make your release (don't forget to test it first).
/your_project
/trunk
/branches
/1.0.0-bugfixes
/1.1.0-bugfixes
/tags
/1.0.0
/1.0.1
/1.0.2
/1.0.3
/1.0.4
/1.1.0
You can do it technically, you branch is not dead nor disabled, but it is not recommended to merge from branch to trunk after reintegration.
You can find a full discussion about the reason for that, here: Subversion merge reintegrate
Basically, it says, that it is possible to merge your changes again to the trunk, but since reintegration forces you to merge from trunk to branch prior to the reintegrate operation you'll be facing Reflective/Cyclic Merge which is very problematic in Subversion 1.5.
According to the article, it is recommended to delete your reintegrated branch immediately after reintegration and create a new one with the same (or different) name instead.
This is a known Subversion behavior which will be addressed in future version (probably in 1.6)
After you reintegrate from a branch into the trunk, you should do one of two things:
Delete your branch. This is the easiest, but it makes it harder to see the branch's history.
Tell your branch not to merge the reintegrate commit. If you reintegrate to the trunk, and commit it as revision X, you can run this command on your branch:
svn merge --record-only -c X url-to-trunk
. However, you shouldn't do this if you made any changes as part of the commit, other than the merge itself. Any other changes will never make it back into your branch.
Actually you need to do a --record-only merge from trunk into your branch of the revision that was created by the --reintegrate commit.
$ cd trunk
$ svn merge --reintegrate ^my-branch
$ svn commit
Committed revision 555.
# this revision is ^^^^ important
And now you record it
$ cd my-branch
$ svn merge --record-only -c 555 ^trunk
$ svn commit
You are happy to keep the branch now
More info here
You can, but you shouldn't. Creating a new branch costs nothing in terms of repository size.