SOT: Best Practices Guidance

I'm hoping to get some guidance before I set up my initial repository.
 This isn't necessarily directly related to Subversion, but we will be
using Subversion so this is the most applicable place I could think of
since I definitely want to be able to take advantage of any Subversion
capabilities that may be useful.

First of all, I'm transitioning from MS VSS, but am not worried about
importing existing history. I lead a product development team and
we're going to be starting development on a new version soon so we've
decided to make a clean changeover and leave the old stuff right where
it is in VSS in case we need it for historical reasons. To that end,
any practical guidance anyone can provide on using the
checkout-merge-commit paradigm would be *greatly* appreciated. This
is our first foray into that method of thought.

The product consists of a core code base and a variable number of
modules which, while part of the product, are sold separately and
effectively decoupled from the core. To this point, we only release
the *entire* code base when we introduce a major release. Minor and
maintenance releases only include modified code.

I've done a lot of reading and it seems like there is a general theme
that I'll stick to pending "practical" feedback from more experienced
users:

1. Set up a single product repository with separate projects for the
core, each module and documentation
2. Within each project trunk, branches and tags folders will be
created/imported
3. Initially, the trunk of each project will contain the code as it
was released in the prior version
4. Branches will be created for each segregated development effort

QUESTION : do all developers typically check out an *entire* code base
from the trunk or only those projects/files that pertain to their
development effort? In VSS-land, of course, we only checked out what
we were actively working on and "got latest" of everything else.

5. When dev/unit testing is complete, merge and commit any changes.

QUESTION : does this remove the branch folder from the repository?

6. To create a release, tag the entire trunk. To create a service
pack/hotfix, tag only those files/folders that need to be packaged and
export the tag contents to the build server to execute the build
process (using Ant).

I know this post is extensive, but I hope some of you took the time to
read it and may be able to provide some assistance if I'm off the mark
anywhere or if I haven't considered something I should have
considered. Any thoughts or input would be appreciated since we're so
new to this.

Thanks.

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