[development] Local repository best practices

[Angela Byron]

I've been doing some research for a client on best practices surrounding 
repository management, and wanted to take this discussion to the 
developer list and see if we could get some general consensus, and 
document it as a best practice in the handbooks.

I found a bunch of discussion on this topic:
* http://drupal.org/node/118936
* http://www.workhabit.com/labs/svn-repository-structure-drupal-projects
* http://ceardach.com/blog/2008/06/development-environment-drupal
* http://pingv.com/blog/cyberswat/200706/project-management-drupal
* http://www.svntalk.com/node/6
* 
http://agaricdesign.com/agarics-svn-repository-structure-for-site-maintenance-and-web-development
* https://svn.bryght.com/dev/browser
* http://www.advantagelabs.com/advantage_labs_svn_repository_structure
* http://www.codegobbler.com/svn-repository-structure-drupal-projects

Most of these discussions are around Drupal *shops* who setup SVN to 
manage the development of their clients' sites, or who host their 
clients' Drupal sites and manage updates via SVN.

However, I'm curious what people generally use in terms of repository 
structure/deployment strategy *after* development is complete, and they 
hand the site over to the client so that they can be self-sustaining? It 
doesn't really seem like they need a vendor branch with various versions 
of Drupal and contributed modules. The repository is around just their 
own site.

We typically do something like this:

/branches:
   This is where "crazy" development happens that will break other stuff.
- /drupal-6-port
- /crazy-new-feature

/tags:
   This is where deployments go. Whenever we move a deployment to prod,
   we tag it first so that we can see a historical record of things that
   were put 'live'
- /2008-09-03-description-of-deployment
- /2008-09-08-description-of-deployment

/trunk:
   The latest development code in preparation of deployment.
   Should be kept stable at all times. Minor fixes can go in here, but
   major ones (particularly porting tasks) get a dedicated branch.

Beneath each directory above is something like this:

- /www:    Drupal files, modules, etc.
- /assets: Things like wireframes, TinyMCE .zip files, and anything else
            that shouldn't be web acessible.
- /db:     Database backup files

What are other people doing for this use case?

-Angie