No hay forma correcta de hacer las cosas, es sólo cuestión de organizarse y seguir lo que se decida.

Dependiendo de la complejidad del proyecto, la cantidad de gente, lo disciplinada que sea y tal suele haber dos formas de trabajo, la primera más sencilla, la segunda algo más compleja.

La forma más sencilla consiste en que la trunk es la principal de desarrollo, donde la gente en general trabaja. Que la trunk sea o no estable depende mucho de lo responsable que sea la gente y lo que pruebe antes de meter en svn. Cuando una versión se entrega al cliente, se suele hacer un branch con esa versión, de forma que en ese branch tienes lo mismo que tiene el cliente y ahí le corriges los bugs y le añades las mejoras, sin que le afecte la evolución de la trunk.

La forma más compleja es la que tú comentas, en la trunk se tiene siempre la última versión estable y cada nueva funcionalidad que se quiera desarrollar se hace en una rama separada que luego se integra a la trunk. Eso no quita que si se entrega una versión al cliente o se saca una versión al mercado, se haga un branch para esa versión, de forma que siempre tengas controlado qué es lo que tiene el cliente y puedas hacer modificaciones sólo para el cliente (aunque luego las incorpores al trunk). Si no haces estas ramas para el cliente, si tiene que corregir un bug en una versión de cliente algo antigua, no podrás hacerlo, ya que tu trunk habrá seguido evolucionando.

Elegir una u otra, como te digo, depende un poco de la complejidad del proyecto y forma de trabajo. Si normalmente un desarrollador hace una funcionalidad nueva y no coincide mucho con los ficheros que tienen que tocar los demás, la primera opción puede ser buena. Si una nueva funcionalidad debe desarrollarse entre varios y encima los ficheros coinciden con los de otro grupo de trabajo en otra funcionalidad, posiblemente sea mejor hacer ramas para cada funcionalidad de forma que cada grupo de trabajo lo hace en su rama y no todos tocando simultáneamente la trunk.

Se bueno.