Use case question

Hello,

I'd like to run a use-case past the group regarding branches and merging.

We use a branching system of the trunk (live) and two types of branches:
project and release.

Project branches are used to developer new features on, while releases
are used to test groups of projects as a whole before being released
(integration testing).

We do svk pull on all branches on a regular basis to ensure that all
work is in sync with what is on live. No problems there (pull works very
nicely)

Ideally, we'd cut a release branch from trunk and then projects from the
release. We'd be able to pull from trunk to release to branch, and push
from project to release to trunk when things get rolled out.

However, we unfortunately aren't in a position where we know which
release a given project will be rolled out as a part of when the project
is first started.

That being the case, I believe that the best way to handle this problem
will be to cut projects from the trunk, and pull from trunk as normal.
When a release is scheduled, the release branch is taken from trunk.
Once a project is ready to be associated with a release, cut a new
branch for the project from that release, and smerge across from the
original project branch to the new one. At this point, the original
project branch is deleted to prevent developers from committing to the
now obsolete branch.

>From this point on we can pull from release to project and push from
project to release once the project is ready for integration testing.

I have created this situation with a trivial test repository and it
appeared to work fine. However, I'm not in a position to be able to test
with a more real-world situation.

Does this seems like a sensible arrangement, and does anybody see any
potential problems in the 'sideways merging' that I am proposing?

Thanks.

-- 

Russ.