Our project is organized into multiple overlapping streams of
development. At anytime there are at least two streams and as many as 4.
(We are doing this, you may have guessed, because we are in a hurry.
Please nevermind whether this is, in itself, is a good thing.)

Would anyone care to comment on whether the following branching scheme
will work:

The trunk would be used for building the current stable release and
doing relatively simple bug fixes. Call this release X. We would create
a branch for release X+1 off of the trunk. Bugfixes would be merged
perioically from X to X+1. When code for X+2 is ready to be checked in,
we would branch off of X+1. Periodically, bug fixes (originating on the
trunk) and new code would be merged from X+1 to X+2. If a new concurrent
release starts up, X+3, we would branch off of X+2 and merge perioically
from it to X+3. And, heaven help us, so on. So far, notice that merging
is always from a lower to the next higher release.

Now here is the thing I'm not sure will work. When it is time for
release X+1 to become the current stable release, it will be necessary
to merge it to the trunk. My concern regards the bug fixes that were
previously merged from the trunk to X+1. These will become differences
on the branch (X+1) that will attempt to get merged into the trunk
(where they originated). My concern is that these differences will
result in merge conflicts. I will shortly try this out on a test
project, but I'll be a little wary that what seems to work OK on a
little test project won't work on a project consisting of hundreds of
thousands of lines of code.

Well, if you've been patient enough to follow along with me so far, do
you think this scheme will work? And, possibly more important, if not,
can anyone suggest a better approach?

Many thanks in advance.

--Chuck