Branching/Merging Best Practices

I'm working on establishing a process for using Subversion once we
have completed a conversion from VSS and I'd like to get some advice
on how/when to merge back into the trunk. I'm not going to carry any
legacy history over from VSS. Instead, I'm going to leave it where it
is and start fresh with Subversion using the most recently released
code base for the product.

From the point of view of an inexperience Subversion user, the most
intuitive process seems to be this:

1. import latest code into the trunk of the product repository
2. create a branch to begin developing the next version
3. create another branch to provide a maintenance release

So now I have 2 branches from the same trunk and I have several questions:

1. After development of the maintenance release has been completed
and tested, is it a good practice (I'm assuming it is) to merge that
"fixed" code into the branch created for the next version of the
product?
2. Since it is a maintenance release of the code that makes up the
trunk, should I merge that maintenance release code back into the
trunk when it's released?
3. The product, like many others, has major, minor and maintenance
releases. Should any or all of these be merged back into the trunk or
should branches be left as branches? If they should be merged back
into the trunk then when is this usually done?

I guess what I'm trying to figure out is the best workflow to use in
the development lifecycle of a product. Any guidance would be much
appreciated. High level process flow suggestions would help me
tremendously.

-- 
Rob Wilkerson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org