We use an attribute "locked" in combination with a before-checkin trigger. This way we can lock branches. But it's easy to unlock them if needed.

The other "exclusive lock" and "Update/Checkin set read-only" mechanisms available in Plastic are only useful when using a checkout-edit-checkin workflow. When using the simpler change-checkin workflow these will not apply.

Therefore the branch-locking feature proposed here could be very useful when using the simple change-checkin workflow. However, there is a limitation to what can be done on other developers' clients, since using this workflow means there is no checkout to indicate the start of a change. Making all workspaces switched to the locked branch become read-only would not be feasible, but we could prevent Checkin to the locked branch and give a warning when someone else tries to initiate a Merge to the locked branch.

We would manually acquire a Lock on a specified branch. Additionally, there could be an option to always lock the destination branch when a Merge is initiated.

The lock could be automatically released when the lock-holder does a Checkin (or a complete Undo) on that branch.

This feature would primarily be useful when doing complicated merges. For normal changes we always have the option to shelve changes or move changes to a new child branch. For a merge, shelving is not a useful option and moving to a new child branch is not a good option either.

Some observations:

A "finalized mark" can be easily applied using attributes, which can then be filtered upon and even used for coloring the branches in Branch Explorer (filters and conditional format). By filtering you can hide the finalized branches from view. I believe you could also apply permissions if you really must prevent users from making more changes to a branch.

I agree with the original suggestion here - concurrent reintegrate merges are unnecessarily frustrating, due to the need for explicit merging when having to rebase any additional changes from the destination branch before Checkin. The main problem is that even completely unrelated and trivial changes from the destination must be explicitly merged! (Even Subversion can usually perform a trivial Update even if there is an uncommitted merge pending...)

Some details of what happens in this kind of scenario:
* I am at changeset A when I start to Merge from a task-branch.
* Before I Checkin, someone else merges another task-branch into a new changeset B.
* Now, before I can Checkin I must merge from B also.
* Finally I can Checkin, creating new changeset C.
* Now, B is displayed as a "sub-branch" that is merged into C.

I can see why it has to be like this to cover all the possible cases, but I wish the update/merge engine could detect and simplify the trivial cases (all changes are in totally unrelated items, or no conflicts). For these cases we should be able to simply Update the workspace (before Checkin) without causing any sub-branching or explicit merging...

In addition to that:
You should have the posibillity to "finialize"/lock a branch, too. So nobody can add changesets to this branch nomore.
Use case:
We develope new features in their own branches, just as normal. As soon as these features are released they are merged back into Trunk (main branch) and from there on all changes on this modul/feature/whatever should be made in speparate branches. Therefor the 'old' feature branch need a lock or finalized mark, which prevents unsers from making changes.