This is our current thinking on this topic. We are (or will be very shortly) struggling with the same problem.

There are really 3 phases of life for a development branch: - active - retired - obsolete

Active development branches are, obviously, where the active development is taking place. A retired development branch corresponds to an active *release* branch. Development has been completed, and the code has been released to test or released to production, but you may still want to mine the metadata from the development branch. An obsolete development branch is for an older release, and its metadata is only of use in specific circumstances (to "historians"). Once a development branch is retired, all write permissions would be removed (but developers would still be allowed to read/open). When it moves to the obsolete state, list permissions are removed (except for historians).

We'd also use a non-flat hierarchy under //depot/dev (e.g. //depot/dev/2004/March/my-project/...) to limit the number of sibling branches visible.

This is not yet a best practice, we are still developing it.

All I know is that it's a Really Bad Thing to delete the closed branch, since deleting is an operation on the branch data and hiding the branch is something you want to do to the metadata. You could obliterate, but that's even worse: you've lost all the history, it's as if that branch never existed. So neither operation is appropriate. I think removing "list" permissions is the closest thing to what you're looking for, semantically.

How does everyone else do this?