Should you bother with SVN branches if you only ever have one?

Question

If we only work with one branch in Subversion, should we even bother? Can't we just work on the trunk to speed things up?

This is how we develop with Subversion:

• There is a trunk
• We make a new development branch
• We develop a new feature on that branch
• When the feature is done, it is merged in the trunk, the branch is removed and a new development branch is made from the trunk

When we want to release to production, we make a tag from the trunk. Bugfixes are made on a branch from that tag. This bugfix is then merged in the trunk.

This is why we make a new development branch after a feature is done. This way, the bugfix is included soon enough in our new code.

Below is a diagram which should clarify:

Now, there's a feeling this isn't the most efficient way of working. We build locally before we commit, which takes about 5-10 minutes. You can understand that this is experienced as quite a long waiting time.

The idea of a development branch is that the trunk is always release-ready. But this isn't true in our situation anymore. Sometimes, a feature is almost ready, and some developers will already start coding the next feature (otherwise, they would be sitting around waiting for one or two developers to finish and merge).

Then, when feature 1 is finished, it is merged into the trunk, but with some commits of feature 2 included.

So, should we even bother with the development branch, as we only ever have one branch? I've been reading about trunk-based development and branch-by-abstraction, but most articles I've found focus on the branch-by-abstraction part. I get the impression that's for big changes that will span over several releases. This is not a problem we're having.

What do you think? Can we just work on the trunk? Worst-case scenario is (I think) that we would have to make a tag from the trunk and cherry-pick the commits we need, because some commits/features aren't production ready yet.