What should be the "trunk" development, or release

I have the unfortunate opportunity of source control via Borland's StarTeam. It unfortunately does very few things well, and one supreme weakness is its view management. I love SVN and come from an SVN mindset. Our issue is post production release we are spending countless hours merging changes into a "production support" environment.

Please do not harass me this was not my doing, I inherited it and am trying to present a better way of managing the repository. It is not an option to switch to a different SCM tool.

Current setup

• Product.1.0 (TRUNK, current production code, and at this level are pending bug fixes)
  • Product.2.0(true trunk anything checked in gets tested, and then released next production cycle, a lot of changes occur in this view)

My proposal is going to be to swap them, have all development be done on the trunk (Production), tag on releases, and as needed create child views to represent production support bug fixes.

• Production
  • Production.2.0.SP.1

I can not find any documentation to support the above proposal so I am trying to get feedback on whether or not the change is a good idea and if there is anything you would recommend doing differently.

Here's my general advice for structuring build streams:

+HEAD - master -> current development 
+ tags
   + version1 
   + version1.sp1 
   + version1.sp2 
   + version2
+ branches
   + version1.sp2.fixes <- at some point, this will get promoted to version1.sp3 
   + version2.fixes <- at some point, this will get promoted to version2.sp1 
   + version2.nix.feature1 <- this is your (nix's) private version2.feature branch 
   + master.nix.feature2  <- this is your (nix's) private new development feature branch.

Basically, you NEVER commit directly to a .fixes or the master branch - only an integration process does that.

Anyhow, pretty much any source control tool will support this model.