Merging - best-practices?

I could use some community help with best-practice suggestions about
handling branches. I have italicized all the steps in here where I
wonder if I am making more work for myself.

Here's the scenario and the layouts being used.

We have one repository that contains all our code. It is arranged in the
following manner:

* trunk
* branches

        * qa
        * projects

                * p1234
                * p1235
                * p1236
                * ...

        * scm_dev
        * named long-term projects

* releases
* tags

The pxxxx is each individual project our company is contracted to do.
The projects generally involve several minor changes to code and
screens. Each branch is a full copy of our trunk which includes code,
screens and our home-grown SCM ant build scripts (legacy application
with no standard support built into ant).

Anyway, the procedure is that a new project gets approved, a workspace
is requested, the branch is created from the trunk, then checked out and
built. The coders then proceed to do their work in the workspace and
make their commits to the branch. Once they finish their work, the
project is tested both in the workspace and at the client's site and
then approved to become a part of our main product. We are considering
creating a second testing workspace so that developers and testers can
work independently of each other. These testing workspaces will need to
be updated and rebuilt more frequently.

The current plan is that project branches will sit out there until the
project is approved, or an explicit request to me is made to synch up
their code with the latest release using svnmerge.py. Once the project
is approved it will be merged using svnmerge.py into the qa branch. The
qa branch is on a monthly cycle where we cut a release and do a manual
regression test (thankfully that's not my nightmare) where we test some
major functionality and retest all the projects that were approved to
make sure they all play nicely with each other.

Once we have a list of bugs and projects that have passed and failed we
correlate those with the qa branch merge commits and then include or
exclude the bugs/projects that are tested and approved and merge them to
the trunk.

This all seems well and good but we are also in the process of refining
our home-grown SCM build scripts and occasionally find bugs. I then
begin to wonder where I should be merging those changes, who will test
them and what kinds of cases are pass/fail for those and if that's
enough. I have decided to create a scm_dev branch that will act like any
other project and will go through the regression process when it is
tested.

But what should be done in the case of a critical scm script fix? For
example, suppose that it is found that the current build could cause
users to be locked out of the server? Should I simply provide
work-around instructions to all workspaces affected or push out the fix
to all workspaces and force rebuilds? Should I separate the SCM source
from the server source to a different repository and version that so
that people can just upgrade their build scripts independently?

Are we handling projects in the best manner possible? Is it a good idea
to separate each project into its own branch?

Thanks,
James

  <http://www.bolosystems.com/>

James Oltmans
Software Engineer
Bolo Systems, Inc.

joltmans@bolosystems.com
www.bolosystems.com

720.212.0687 direct
866.987.2238 x107 toll free